I do not know how far you have gone into sprite making, rom hacking and graphics theory so I will try and keep this relatively simple.
First screen shots means emulator and if you have one like desmume you can use the various viewers to spit out your sprites in a sprite sheet friendly way (you did not think most sprite makers chose the lime green or pink backgrounds for no reason did you?).
Although it does not have the nice pink background like some other roms here is an example with the homebrew game POWDER and the tile view:
http://pix.gbatemp.net/32303/spriteripdemo12375.jpg (the OAM viewer is even better for most games).
Unused (assuming in this instance you do not mean things that were cut from the final game but left in the code but things like death animations you might not normally see) sprites can also often been seen in the memory as well.
Do note that these viewers may not apply a given palette at a given time so it may look odd until you find the right one (it is actually a shot from a tile editor but it has what I am talking about
http://pix.gbatemp.net/32303/lozdemo.JPG ).
After this you are in the realms of proper rom hacking- the DS SDK does have sprite formats (technically general image formats), a basic description (and more importantly common extension names).
http://tahaxan.arcnor.com/index.php?option...ult&lang=en
Pulling apart roms like this is a way to get those "unused" (as in axed from the final build) sprites you mention.
Of course these files can be found within sub files (narc/carc files often house entire tile, palette and layout data) as well as see compression (a carc file is a almost always a compressed narc file). Tools like crystaltile2 have reading ability for these files (I did a basic guide in the rom hacking documentation about halfway down this post
http://gbatemp.net/t73394-gbatemp-rom-hack...t&p=1221059 ) along with a few others.
The end results can be almost exactly what you want
http://pix.gbatemp.net/32303/gundam2.JPG
All this being said developers are not bound by Nintendo to use their formats and indeed many developers do use their own. Often they are just tile in a file you can scan through and see with a tile editor (the DS uses the same formats as the GBA so if your tile editor does not mention DS but has GBA you should be safe). Going slightly off on a tangent but some of the compression applications for the GBA (remember the same formats thing from earlier- it carries over somewhat into compression) have tile viewers built in as well-
http://www.romhacking.net/ has a bunch.
I have also seen the developers of DS games use the 3d engine for what amounts to 2d sprites on the screen (platform games are great fans of this as it can make for fluid motion, high detail and things like shadows without having to crack the whip over your sprite artists for 5 years). We do have 3d tools for the DS of varying quality though (a screenshot
http://pix.gbatemp.net/32303/phantdemo1.PNG and an application:
http://www.romhacking.net/forum/index.php/topic,8407.html )
That is not to say you have to use one or the other- if I want to use an emulator to rip a music track that does not play until the end of a game I will instead hack the music file to play said song instead of say the title screen music. Even if the developers are not using nintendo formats in a game the format will usually be consistent so you can instead make the final boss appear as one of the starting characters/enemies and the like. It can get a bit troublesome if you want to say replace a single tile giant rat with a 10 tile boss monster but it is usually worth a go (not all games will be quite as nice but if you pull apart new super mario brothers most characters (OK 3d in this case) will be in one directory).