Theoretically
I2C and SMBUS are essentially compatible as long as you are operating at 100kHz bus speed. The datasheet on page 15 (7.4.3.1.1) suggests to read a register you (as a master) have to do:
Start
SLA+W (slave acks)
Command (slave acks)
Repeated Start
SLA+R (slave acks)
READ data byte low (you ack)
READ data byte high (you ack)
READ PEC (you ack)
STOP
The appropriate SLA is 0x5A. Just like with I2C, you will need pullup resistors on the SCK and SDA lines (3.3kOhm should be fine). Command value will depend on what you are trying to do as described on page 16 (7.4.6).
Reality (?)
However, there is a paragraph (7.4.1) on page 13 that says:
In order to provide access to any
device or to assign an address to a SD
before it is connected to the bus
system, the communication must start
with zero SA followed by low RWB bit.
When this command is sent from the MD,
the MLX90614 will always respond and
will ignore the internal chip code
information.
... now that is a vague description of a specialization of the protocol at best, but it appears to be what the github code is exploiting.
If one is to believe the github code, it is actually illustrating an undocumented protocol behavior. Namely:
START
SLA(0)+W (slave acks)
Command(7) (slave acks) (writes to the RAM read-address register the value 7 = TOBJ1?)
STOP
START
SLA(0)+R (slave acks)
READ low byte (master acks)
READ high byte (master acks)
READ pec (master nacks)
STOP
I've seen this "flavor" of I2C interaction before, but I'm with you that it's not described that way in the datasheet.
Sidenote on PEC
As for "how you generate the PEC" it's described on page 14 at the bottom of the page:
The PEC calculation includes all bits
except the START, REPEATED START,
STOP, ACK, and NACK bits. The PEC is a
CRC-8 with polynomial X8+X2+X1+1. The
Most Significant Bit of every byte is
transferred first.
Basically it's CRC-8-CCITT (see wikipedia) - implementations exist, just google for it, or post a separate question about CRC...