Such an idea has been floated in the past (my last pondering of it -- http://www.romhacking.net/forum/index.php/topic,16070.0.html
) though getting something done is nice too.
The main problem with this sort of project is it tends to end up either
a) Complex enough that becomes a programming language unto itself. Text extraction tools are often a good example here.
b) Inflexible enough that you might as well not bother.
c) An actual programming language though probably not a good one (see something like romulan)
d) Another program with another extension format. As of the last few years and things like tinke or everything including lua or python modules then you face some steep competition here as things like tinke have serious functionality before you even start extending things.
From what you have said thus far you are probably not far enough in ROM hacking to break out of that mould. By all means make a game, system, franchise or format specific tool (we could always use more good ones of any of those) and I absolutely encourage programming it in such a way that you can easily come back and adapt it (nice function names, comments, no hardcoded variables anywhere*, variables maybe even kicked to an external source sheet, variables also means the words you use so people can translate it and so forth)
*no not even that one.
On d) from the list above. This gets interesting as we already have several standard formats. Table files (the three or four formats already out there anyway) and nobody is really going to want to accept another one.
Graphics... I already have http://code.google.com/p/tiledggd/
and it is great, however it is not so hot with some of the more exotic alpha formats seen in 3d textures so there is definitely room for improvement. Similarly some of the quasi compression/referencing tile formats that the GBA and DS support can be troublesome with that (GBA3 Xbpp and GBA2 4bpp being the names of two of them, seen in actual games as well).
Even on assembly we have fairly accepted formats in some cases. On the DS (and I guess perhaps the GBA) there is the NEF format (used by no$gba, crystaltile2 and recognised in many places, a fraction more on it http://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-rewritten-for-2012.73394/page-4#post-2782288
) to say nothing of this is when lua often appears.
More generally. "so that you can edit them and easily put them back in" Will this include pointer support at both file level and console level? It is not so useful without it when bookmarks exist in a lot of things and copy and paste exist in hex editors or cut and copy stuff exists to use with the command line. Speaking of pointers you have several different types of them to deal with before you even come to the file formats -- the NES, the SNES, the GBA and the GBA (and DS for that matter) all have somewhat different styles of doing things (see some of the text decoders) and can be encoded oddly.
On compression http://www.romhacking.net/utilities/826/
for the GBA/DS I consider to be reference grade implementations of it. If you wanted to make a generic LZSS compression tool it would probably not even be that hard (you have window length, flag type, flag distance, split between read back and length of read, start from the end or start from the start compressions. That would probably also be the hardest give or take exotic huffman (and not so much uses huffman).
Encryption. If you can not implement a generic XOR (about the main type of encryption seen on consoles) then it does not say great things.
On assembly. I already mentioned the NEF format. It goes a lot deeper though (later posts in http://www.romhacking.net/forum/index.php/topic,16594.0.html
just begin to hint at it, http://www.keil.com/support/man/docs/armasm/armasm_Cacdbfji.htm
might be warranted after reading it).
"simple descriptor file (a RPL)"
A perfectly valid way of working, however we do have tools for various formats (many general things but more often than not compression) or indeed whole games (Atrius' golden sun GBA tools for the others reading) that will search the game for various formats.
As I am just dropping data and picking holes at this point I suggest you look at 12 different things plus the links I have already dropped.
1) Atlas and the normal text dumping tools. http://www.romhacking.net/utilities/224/
2) The recent discussion on kruptar. http://www.romhacking.net/forum/index.php/topic,16496.0.html
3) Tinke. https://code.google.com/p/tinke/
4) Crystaltile2. http://www.romhacking.net/utilities/818/
I have some very old source code for it as well but that is probably not so useful.
5) Romulan. http://stealth.hapisan.com/ROMulan/ROMulan.html
6) Tahaxan. http://www.romhacking.net/utilities/455/
7) Lowlines' console tool. http://www.romhacking.net/forum/index.php?topic=8407.0
Fceux lua. http://www.fceux.com/web/help/Commands.html
(also the basis for a lot of other emulators). Whether you want to have your tools reach out and touch emulators (memory grabs, cheat making, palette/VRAM grabs and such)
10) Pretty much any of the non pokemon game specific stuff (anything with Mario in, golden sun, advance wars and fire emblem are usually good bets). http://gbatemp.net/threads/mkds-course-modifier.299444/
(might take a bit of digging), http://forums.warsworldnews.com/
being reasonable jumping off points for each of those.
11) VGMtrans. http://filetrip.net/nds-downloads/utilities/download-vgmtrans-92909-f27960.html
12) VGMToolbox. http://sourceforge.net/projects/vgmtoolbox/
As you have already found this is a massive project and many around here will have been around to see several wide eyed neophyte ROM hackers crack on with making "the great ROM hacking tool" only to decide they have bitten off more than they can chew. Two years, a github, a nice language like python and most of what you have said say this might get further than a lot of them but I doubt it is enough to overcome a lot of the doubts people around here might have.
Link I have not been able to fit in elsewhere http://nvwr.googlecode.com/svn/trunk/libs/