Oh, I was just using Colemak as an example, it needn't be included all the time. And for F13 etc, unless mappings were in the config file, they wouldn't take up any EEPROM space. There are some small tables used to remap the FAKE entries to usable codes, but these live in ROM, and there's plenty of that :-)
There's certainly no reason why the compiler couldn't read multiple input files before spitting out the binary EEPROM image, but I don't think there's a need for a keyboard database since the majority fall into one the four types already handled (any keys with special codes in, say, extended set 2, would need modifications to the hardcoded part of the converter anyway).
The web server idea is great, but would need to hande uploads carefully, and need a server that stays up, etc. Another option is to use a web browser for UI, but have it all run locally... the snag with that is that people update browsers, and it might break something (particularly since we'd want to read/write files), so could be a maintenance headache to keep the code compatible. On the other hand, everyone has a web browser already, so there's no scripting runtime to install. Third option would be some scripting language which has reasonable cross-platform UI support (python?). The latter has the advantage that it's no problem to call the driver to upload the compiled binary to the converter.
So far, I've been thinking only of uploading the remaps and macros to EEPROM using this setup (i.e. The main firmware would not be reloaded each time). This means you don't even have to press the button on the Teensy in order to change mappings, and your keyboard stays operational throughout. That's nice, but there's so much ROM space free, that it's tempting to reload with a modified firmware (which is what you were thinking...?).