I cannot see any obvious reason it shouldn't work ( ignoring the SYMBOL typo ) and it's how I'd do it - Leg 7 SDA, Leg 10 SCL is correct, 4K7 pull-ups should be okay.
I'd suggest changing 'i2cfast' to 'i2cslow', removing 'setfreq m8', and seeing if that does any better. It could be that the I2C command version is simply running too fast for the MAX518.
The bit-banged code violates the I2C specification in that it always keeps SDA driven high or low, even when it should be high-impedence ( input / floating ) during ACK - Unless you have a diode, from SDA pull-up, pointy-end to PICAXE leg 7.
Without the diode it is possible to damage the PICAXE output pin; it's high, the MAX518 shorts it to 0V, lots of current. This is a short term event so there's a good chance the PICAXE would survive but no guarantee of that.
An improvement without such a diode would be to remove the SDA=1 after the NEXT and put an SDA=0 after the SCL=0 in the FOR-NEXT loop. This is electrically safer and, as you're not checking the ACK is actually generated, what's on the SDA line at that time should not matter.
The differences between the bit-banged version and I2C command version is -
* The bit-banged version runs much slower than using the I2C commands.
* The bit-banged version hard-drives both SCL and SDA, the I2C command will soft-drive both SCL and SDA. The pull-ups are not as important ( not even necessary ) for the bit-banged version, they are very important in the I2C command version.
* The bit-banged version does not check the ACK reply, the I2C command version likely does.
I'd therefore presume the reason it doesn't work comes down to one of the above.