If I'm not mistaken, the actual encoding process of Fraps uses the CPU more than the GPU (which would allow for widespread utility). Even under ideal circumstances however, where the sofware uses the GPU for encoding when available, you'll find with your current model of video card you'd be out of luck. Most of the available video memory (if not all) and most (if not all) of the GPU's power will be dedicated to running MW2 at the settings described. In order for encoding to "work" in this case you need a few things. First, you need a memory buffer sufficient to hold at least a single frame (and likely several frames at once). Once all post processing is done, at the very worst, this amounts to the resolution multiplied by the color depth (at my current settings, that works out to ~ 55 megs per frame). Then, you need the actual processing power required to do the encoding process (converting still images into video, applying the audio track, compressing the result) which more or less amounts to GOBS of simple number crunching. Finally, you must stream the result to the hard drive.
You therefore have three potential bottlenecks: the hard drive, the video card, and the CPU itself. If your GPU has insufficient power for the task, the processing and buffer job is relegated to the CPU and RAM (and that's without actually knowing precisely what parts of the machine Fraps leverages). If either of those are insufficient, you are going to have to start losing frames somehwere. The Hard Drive bottleneck is a bit trickier to describe. Since the resultant video has to go somewhere after it leaves the register, the probable first stop is the system memory. Given just how quickly high quality Fraps consumes storage space, you'll obviously want to stream it to a larger storage device. If the hard drive cannot write as quickly as the data is being produced, your "finished" buffer will start to fill the system memory. Once system memory is full and your hard drive is maxed out, swaps to and from memory will be tricky at best, resulting again in lost frames somewhere.
Some people have asserted that the problem may lie in lesser areas like memory clock speeds and whatnot, but this is almost certainly not the case. The average system's true bottleneck does not lie in the rate at which memory can be read or written, or on the speed of memory operations on the register (the memory on the CPU itself - any operations actually take place here and thus it is actually silly fast and incredibly tiny) but on the bus itself (that is, the path between devices the data must take). That said, it is possible that you would see an improvement with faster more efficient memory, but it would be the very last thing I'd examine.
It is actually easy enough to determine at a glance if the probelm is system memory or CPU. Simply run perfmon (or a fancier equivalent), select the appropiate things to moniter, fire up the game and do a quick fraps capture. The results will show you quickly enough if the problem lies in the most likely areas. There are programs that will also track the performance of the GPU but their name escapes me at the moment. I am currently unaware of a pure software solution to monitering register, bus and memory performance at a granular level as any option I've encoutnered relied on (rather expensive) hardware in conjunction with software.
Also, it is worth noting to those who suggested SLI (or crossfire) as an option: This may actually harm performance. The reason is simple enough - if the FRAPS process relies on the CPU itself, the use of dual video cards will reduce the available power. On most (by which, I've never seen a motherboard that did otherwise) systems, the CPU is actually used to play traffic cop for the cards. When SLI was first released for example, only the most taxing games available at the time actually saw an improvement in framerate (Doom 3, Half-Life 2 and Far Cry) because the bottleneck in other games was not video performance when using a top tier video card but rather CPU performance.