So, I'm looking to learn how to use WabbitEmu to debug assembly code. I've never debugged a full program before in it, as I've never gotten to this point. So, are there tutorials or can someone here who has done this drop a few pointers. Thanks.

Here you go: http://xkcd.com/138/

The basics of debugging with a debugger go something like this:
1) Test your program, identify some incorrect behavior
2) If you can't immediately tell from where in your program the incorrect behavior is coming, make some educated guesses. Using your listing file, determine the address(es) of routine that either could be the culprit or could be leading to the faulty code.
3) Set breakpoints in those routines. Run your program again, and single-step until you see the problem again. Often this involves stepping over calls and bcalls the first time to reach the problem quickly, use that to narrow down where the problem is occurring, and then stepping into the call in question to track further. Often this set breakpoint, single-step, narrow down issue step is repeated several times.
4) If necessary, use the memory view to keep track of the values of data and variables, and understand any deviations from expected behavior.

Hope this helps.

Another helpful thing with breakpoints is setting breakpoints on writes/reads, sometimes your values are getting overwritten in places you don't expect (maybe your LDIR is one byte too long, for example, or you miscalculate a pointer somewhere).

As Kerm mentions, when going through a program, it can often be useful to step over a call and see if register values, variables, etc. are what they should be. If they aren't, then you can step into the call and analyze it more closely.

You really should write your code small chunks at a time, writing it all at once is a recipe for disaster as it's hard to tell what's broken and what's not (and things are almost always broken the first time through). Also, even if you get one piece of code working, it's hard to know. For example, if your LCD display routine doesn't work, it's much harder to test if your sprite routine is working. If your sprite routine isn't working, it's harder to test if your character movement stuff is working. If the tilemap isn't working, the tilemap scroll routine won't return anything useful. And so on. Working one piece at a time will make your code much easier to handle. You can also document it well once you've got it working so that if you need to go back and change things later (or fix bugs) you can find your way. It's also good practice to mark inputs/outputs and give a short description of what the purpose of the routine is.