Assembly wise you might have tried running before you can walk as far as your learning choices go, your examples of potential projects are fine for early stages and I will cover something of them shortly.
I find it useful to gain an understanding of the core commands and then branch from there. In this case you don't have much in the way of extraneous commands (compared to say someone learning modern X64 where it will have things nobody really ever uses but have to be there for completion) but you can shrink it down.
It is important to understand concepts of timings, what registers are traditionally used for what and so forth but for now if you are editing within parameters of a game they are less important -- back to the idea of infinite lives before, say you find the thing that adds lives in this game and instead of giving you one extra life you make it give you two (maybe you are making a kind of easy mode hack). Timing differences between add r1, #1 and add r1, #2 (that might be the wrong syntax for this but hopefully it still makes sense) are nothing but you still have just done an assembly hack, and might well have radically changed how the game plays out for most people.
Moon jump then.
1) If you see it rendered as a cheat then it will mostly be for a game with a double jump. I mention it mainly so you are aware of such things. The idea is the game will do the second jump in the air, set a flag and then not allow another double jump. Your cheat forces the part from "set a flag" to always be "no second jump done yet" and thus pressing jump sees you able to fly to the moon.
2) Actual jump tweaks. The character will be on the screen and its location controlled in some way. Most characters in 2d games are sprites and thus taken care of by whatever passes for the OAM on that system (here it is called the OAM http://bgb.bircd.org/pandocs.htm#vramspriteattributetableoam
). 3d is also similar in many ways but on rare occasion the whole world might move instead or it might be the camera that moves, enough of that though.
So you find what OAM value controls your sprite -- these nice OAM/sprite/tile viewers being there for a reason. Failing that most systems rarely have more than a few hundred sprites they support so you can load up the memory viewer for that area, make sure it updates in real time and jump a few times, any changes should be fairly obvious.
What you do here is up to you. You can watch that area, start a jump, advance a frame and see what changed it. Follow that back and you eventually find the thing controlling jump height. Alternatively you could set a break on write for that OAM area and it will pause the emulation and say "this instruction wrote this area, this is where the instruction is and what immediately follows and precedes it".
Said jump height instructions might be slightly complicated by it not being a simple "add 2 per frame until you hit 20, then minus two until you hit something you can land on" type affair -- proper acceleration due to gravity/parabolic curves were popular from way early on.
Ultimately it might be something else that controls the height and the OAM is just a side show* but as it is directly linked to it then you will find your height variables soon enough. What they might be in a given game varies, especially if different characters have different abilities, but should be able to be found.
*similar to how the text on the screen is probably not going to reference the text in memory after it is drawn on the screen and thus you can change the nice text in memory all you like but it is not going to be reflected in the contents of the screen.
Hitboxes can be marginally more complicated ( http://dammit.typepad.com/blog/2010/09/street-fighter-ii-hitboxes.html
), and some systems (usually older or odd arcade ones) don't actually use them and instead have automatic collisions in the OAM/sprites, but follow much the same logic and will have the OAM involved somewhere. This even if it is just deciding how to do the maths to send the relevant sprite in a recoil animation.
Also it is for the GBA but you might like http://www.coranac.com/tonc/text/video.htm
It covers how the video side of things works on the GBA (and it is not far removed from the GB/GBC, or indeed most other 2d devices).