The scope of ROM hacking kind of gets divided along similar lines to homebrew in terms of can work on hardware or is emulator/enhanced hardware only, however that is not the most useful distinction.
For the emulator/hardware stuff most will usually think of either SNES hacks that used quirks of emulators to make life slightly easier or the stuff a lot of people do with games rendered in 3d hardware where they replace textures, add antialiasing and various other things -- some of that is done to actually give the game textures in the first place, increased polygon counts for models or higher resolution textures, other times it is an end run around learning what I would probably call ROM hacking proper; if the text is rendered on the 3d hardware at some level it becomes a viable target for texture replacement, however most around here would consider that a horribly overcomplicated (even if the barrier to entry is more likely to be "can use gimp/photoshop/paint.net") and impractical way to set about such things. It can however go from the more subtle stuff with NES mappers (the NES carts often had extra hardware to increase their capability in various ways, not anywhere near as much as the SNES but still a lot) to things like some of the hacks with Lua enabled emulators (Lua the programming language is commonly added to emulators and can read the memory of a game, inject things in it and also put extra content on the screen, have a look around tool enhanced speedrun (TAS) forums for more there*) -- http://www.romhacking.net/forum/index.php/topic,18717.0.html
*the two that mostly feature it as a stock would be FCEUX for the NES and Desmume for the DS, most systems will probably have a fork of an emulator with it though.
Without looking at code you can usually edit text quite easily once you know how (see pointers and encoding/tables), graphics (give or take compression), some music on some systems and levels are also often possible. Eventually though you will have to look at the actual machine code via a disassembler, bonus here is you will tend to have an emulator you can stop, restore states to, set to watch/break certain locations and much more besides. To get most places in the assembly hacking you will probably want to know the assembly for the given chip(s) and/or system in question (if that was the megadrive version you were looking at then it has a 68K chip and a z80 that mostly does sound, compared to the SNES the megadrive is not quite as commonly hacked outside of Sonic but that is OK).
Equally as ROMs of old games do not tend to get recompiled any locations you find for whatever will tend to stay that way forever more -- if you know a sprite for a given character is at this location, using this format and these colours then you can make a tool easily enough to decode said location and allow people to doodle on it with said same colours. On the other hand a lot of those tools can be quite generic and have no deep logic to them -- graphics are usually determined by hardware so you can add decode methods for various systems (they are all quite similar but with enough subtle differences that you need to play to them to see anything), add means to set the width and height of a tile, set a location you want to start decoded and bam you have a tile editor. Text might not use ASCII
but it will probably still use 8 or 16 bits to encode text values, make a hex editor that can decode using a user defined table of values and you have something that can decode text. For most older systems the sound was left up to a given developer, minor exception for the Amiga which frequently saw all sorts of common tracker formats used, but newer ones like the DS have a sound format that is shared by the vast vast majority of games.
Not many people find much use in looking at assembly line by line (the closest most people will get for this is in graphics editing where you can usually open the thing in a tile editor, set the mode, press page down enough times that you have looked through the entire ROM), usually you will have a plan of attack. For instance if I wanted to hack in infinite health I would find a point in the game, do a savestate (optional but suggested), make a cheat (memory search) for the health value for that character, take said memory location and give it to a debugging emulator to pause when something touches that location, said emulator would give me the instruction that changed that location and I can either follow it up the chain or simply change instruction so it does nothing. Equally it is for that reason that a lot of people will probably learn the basics of cheat making before tackling assembly proper, though if you wanted to learn graphics tracing or something instead then that is fine.
1) UI redesign is one of the things I like to do, indeed if I review a game I will usually take the time to consider the UI in preference to a lot of other things. In this instance though it is more likely to involve assembly. There are a small handful of games that do it with their text engine but is still a small handful, and most of those are more the static UI stuff informing you of something rather than menus.
2) Doable in a general sense, how it will play out for a given game remains to be seen. I do not imagine it will be a loading/processing mask (if it was a 3d game then the chances of such things rise considerably for some reason) but it is not unheard of. If you are using one of those lua emulators you might be able to get it to fastforward if you can detect it is an enemy move time.
3) If it is initial enemy placement then that is probably quite doable (it is likely a separate table in the level layout). Move costs might be a table again; such things are usually laid out on top of graphics rather than have the game decode graphics and go backwards, it is certainly the case for 3d games, but it might also be that the graphics pull from the initial table. If it is graphics pull from the table then you will have to determine where it calculates move costs and adjust that in the game.
Syntax and coding for old games... technically the SNES did have some compiled games, however compilers did properly not start appearing and being used until the PS1 era and decompiling is not really something that ROM hacking does much of unless a game was written in some kind of interpreted language (be it something like ZZT, SCUMM or right up to the modern day with Lua -- many a commercial game on the DS has some Lua in it and a few even use it near exclusively). Most games before then and many games during and after that were coded with extensive assembly language, obviously this changes for every processor and hardware setup but if you learn more than two CPUs, especially if one of those is x86, then you tend to be able to change easy enough; you will have instructions to do maths, do boolean logic, shuffle things into and out of registers, shuffle things into and out of memory, ways to interrupt code to do something else and most of the time it will have some location in memory to do something that the CPU might not be as good at (most likely DMA to shuffle large amounts of data from the ROM into memory, or memory to another type of memory).