Electronic – DS1077 to drive a PIC’s clock

I would recommend reading the datasheet again for that device. It sounds like CTRL0 and CTRL1 can also be used as output enables depending on the devices control registers MUX and BUS. This would explain why when you assert CTRL0/CTRL1 the oscillator output is disabled. Another thing to note is that the datasheet says the register values are store on an internal EEPROM, but only after a write command is executed. It could be possible that you think the registers are set one way, but when you power cycle the board the previous values are being loaded from EEPROM. I've worked a lot with I2C clock chips and every time things weren't working it was because I miss interpreted one of the register values. Write each register out on initialization then read them all back to make sure you initialized them properly. Compare the results to the datasheet to see if they make sense.

EDIT: It appears that the CTRL pins can also be used to place the device in a power-down mode which would explain why it's not responding to I2C at times.

Programming one PIC by another PIC is perfectly possible, and when you use LVP the circuit is trivial. The effort is in writing the code on the master PIC that implements the programming algorithm, according to the specs in the 'programming specification' document for the slaved chip. This is what most programmers (the hardware thingies, not the people) do, but note that in most cases the programming algorithm is at least partially implemented in the PC side software.

There are various examples that you can check, the pickit2 has already been mentioned. My Wisp648 firmware (in Jal) and PC side software (in Python) are also open source, and IIRC the software for Olin's programmers is too.

But the programming specifications are not that hard to read an implement from scratch, especially if you need to support only one target chip. Essentially you force the chip into programming mode (release reset while LVP is active), and then you feed it commands and associated data (in a SPI-like fashion), observing the required timing. Afterwards you can use an off-the-shelve programmer to check whether your programming effort was successful.

Another solution would to to put a bootloader in the F88. The down side is that you need to program the bootloader (but a suitable one might exit already) and that the bootloader takes some memory, but the up side is that you can choose the communication protocol (or stick to an existing bootloader, which will often use a UART-based protocol).