For the sake of argument, let me propose a system that simply aids in doing just that. A system that needs no library functions and has low overhead, but requires individual user management by slightly modifying the sketch source files. Some automation may be possible, but not assumed or required.
The Kickstarter campaign says that there will be an Arduboy Arcade. Presumably, this will be a central repository of games and other sketches officially sanctioned for use with the Arduboy. I assume that one or more people will be responsible for adding to and maintaining this repository.
I propose that the Arcade maintainer(s) also be responsible for one more thing: Issuing and keeping a list of EEPROM user IDs. The ID would be a 16 bit number similar to a USB Vendor ID. To get an ID, a user would simply ask a maintainer for one.
The handling of EEPROM use by sketches would rely on just 3 standard items, which would appear sequentially, near the top of the sketch's main sketchname.ino file or optionally in a sketchname.h file :
The offset to the start of the sketch's EEPROM area. This would be the same in every sketch, except for the actual offset value:
#define ARDUBOY_EEPROM_START xxxx
where xxxx is a decimal number. This value would be the only thing changed by the user, to set the sketch's EEPROM to an area unused by any other sketch or reserved for the system.
The length, in bytes, of the EEPROM area used by the sketch:
#define ARDUBOY_EEPROM_LENGTH xxxx
where xxxx is a decimal number.
This value might only serve as a reference for user calculations, but could possibly be used (and maybe even set) by an automatic management tool.
The EEPROM area structure:
uint16_t userID; // As assigned
uint8_t sketchID; // User defined. Allows more than one sketch or variation per user ID.
// remainder is user defined
When a sketch started, it would first check that the values for the userID and sketchID stored in EEPROM were correct. If not, this would indicate that the area was allocated to another sketch or had never been used. The program would warn the user then offer to initialise the EEPROM area, or abort, or possibly allow running in a mode that didn't use EEPROM.
To make it less likely that a false positive match on userID and gameID occurs, they could be slightly obfuscated, such as by xoring with AA55 A5.
The initial value of ARDUBOY_EEPROM_START, as shipped, should place the structure at the high end of EEPROM. The user would then change it to be somewhere in the area they were maintaining, if they decided they wanted the sketch to be in their library.
By having consistent, unchanging names for the defines and structure, it makes it much easier for the user to know how to edit the sketches. They'd still have to do the calculations themselves and keep records however they wished (I'd consider using a spreadsheet). This same consistency would possibly allow a program to scan, calculate and batch edit a "library" of sketches.
Note that the locations of EEPROM areas don't have to be contiguous. For instance, unless space became tight, I would consider setting the start locations on standard boundaries, with some extra space between used areas. This would allow for extra storage added by later sketch versions.
One other task for the Arduboy Arcade manager(s), would be to make sure a sketch that uses EEPROM follows this system, before accepting it, (or at least make sure that it's well documented that it doesn't).