This is probably better suited to the rom hacking section, indeed we have had a few conversations on the matter in the past there but they are probably buried deep so no worries there.
Short version is no general purpose hack (the slowdown hacks you might see for flash carts are not true slowdown but flood the CPU with instructions in an attempt to slow the whole thing down) although you might be able to do something on a game by game basis.
Your main two methods will be
1) disable vsync options. Despite the DS being relatively weak in terms of computing power games can still operate faster than the screen/person playing can do stuff and this is usually tied to vsync. If you manage to disable things that use vsync to limit speeds the code will run as fast as it can and the effect is a seriously increased speed although graphical errors and maybe game crashes will be a side effect (several reasons but one of the big ones will be known as a race condition). If you ever saw some of the very first GBA carts that were running on GBC vintage hardware (and probably the GBA slot supercards) this is probably what the speedhacks were doing. Your DS emulator (and indeed any emulator that offers such speedup options and in the case of emulators slowdown as well) will probably be changing the rate at which the DS it is emulating is running (outside of some very specific emulators that are aimed at individual games most emulators will build a model of the hardware and run things through it for all the different components (sound, 2d, processors (often more than one), 3d, network and other such things) attempting to keep it all synced up hence emulators often requiring serious resources to run properly or hackjob methods that do well for most games but break others).
2) Actually changing the game code. You have the issue that maybe stuff is actually being done in the background while images are displayed (this is especially true of trying to remove developer logos on game startup) and if the developers did things oddly (certainly not unheard of) you might cause unexpected behaviour. The general idea will be it will hook and add so many to sprite movement each cycle/vsync and you tell it to add more (if the rate is 10 pixels per second you find the value that adds that much and double it and hopefully halving movement time) or outright negating the entire process and skipping to the end- in pokemon the battle code/underlying database/spreadsheet is probably kept apart from the graphical and musical aspects (indeed it should be but see again developers doing odd things- there are some amazing programmers working in games but there are a lot of people that probably could not hack it elsewhere too) and probably branches off when things need to happen and flagging things when it is done which means you get to find where the branch happens and what the end condition/return should be and mimic that.
Both of these methods are ASM level hacks almost without question (so very few commercial DS games use interpreted languages you can modify although some abstract things away from vsync into a more general counter) and probably some of the harder ones to do.
The third method of redo game routines for speedup does not really apply here although some have done it (among other things several AKAIO hacks for games, the simple act of removing AP does a lot, http://www.dwedit.org/dwedit_board/viewtopic.php?id=480 and maybe the early castlevania speed patches* if you want to look at it that way) and it can be useful. Indeed unless a game was noted for bad speed (usually text scroll speed) or something similar or I was doing it for a console code emulator/early hardware (if you have an emulator that is pushing the hardware to the limits like it often does on a console for instance- we saw a few for the SNES for the GBA and DS emulators for them**) I would probably do something like this instead of attempting a hack in the realms of 1) and 2).
*akaio again and later others properly fixed the sub optimal code on the original game but in the meantime people disabled the sound thus giving more resources to the other processes going on and hopefully dodging the crash.
**hacking roms for improved emulator usage is arguably a different topic entirely and not one that is that well practised these days.
The fourth method of overlocking the DS was attempted once or twice but I would be hesitant to try it.