The major issue is reliable PC <> Arduino comms.
As the Arduino makes no provision for hardware handshaking, you have three choices:
1. Keep the baud rate low enough so that even with the worst case delay to write to a file on the PC or to write a page to the EEPROM, neither the PC's or the Arduino's serial receive buffers will overflow. As the worst case delay on the PC cant be guaranteed, you'll need to set the baud rate very conservatively and have some means of detecting if data has been lost.
2. Use a higher level protocol that transfers the data as packets, with a unique packet number, length check and checksum so that retransmission can be requested for any packet that has lost or corrupted characters. This will have a considerable impact on the Arduino code, as you must wait for each packet's reception to be confirmed before you can reuse the packet buffer + you have to handle the overhead of building each packet. On the PC side, you'll probably need custom software, though it may be possible to reuse file transfer software designed to handle transfers via serial modem, with a well documented protocol and packet structure.
3. Use Intel HEX as the data format, implement XON/XOFF handshaking for the PC<>Arduino serial link, and code the Arduino loop() function to be non-blocking so it can always respond to a received XOFF quickly. Unfortunately the Arduino Wire (I2C) library uses blocking code so either you need to use a non-blocking Wire replacement or bypass the Wire library and use the AVR TWI hardware interface directly, otherwise you risk dropping data while waiting for an EEPRM byte or page write to complete. On the PC end, use any terminal that supports XON/XOFF handshaking, capture to, and transmission of a file. As there is no check that whole lines haven't been lost from the Intel HEX file, you also need a verify mode on the Arduino that compares received data against existing EEPROM contents, and repoorts any discrepancies and the total number of bytes checked.