Capturing the ever-changing codes over a long period of time still won't get you a way to emulate the key generation in software. The algorythm and the private key that generates it are not part of the six digits that you keylogged. It's hard-wired into the key tag.
If we were discussing stealing the six digits of log information, you would be correct.
This is, however, not the case I'm presenting.

In a way, this is like suggesting that because I have a MAC address tied to my computer's hardware, that I can't have my MAC trivially stolen. Because the address or key is used in software, or the hashes it creates are visible to applications running on the client's machine, the private key is still fair game.
The obvious difference is MAC addresses are given in plain.
Steal the private key from who? The user can't get access to it - it's embedded into the device, and if the server is compromised then all bets are off anyway.
Theoretically, since the device needs to authenticate against an application running on their PC, all one needs is bad authentication code at the application layer of the machine running the device, and the security will be compromised.
Similarly, a hardware attack from code running on Ring0 of the infected machine could also be effective.
I don't have one of these tokens myself to test this (I use RSA in software), so instead I'll link three papers on how to successfully implement attacks on these devices.
http://eprint.iacr.org/2003/162.pdf
http://eprint.iacr.org/2003/205.pdf (improvement of the previous method)
http://malpaso.ru/securid/initial_securid_analysis.pdf (second opinion using hardware sniffing tactics)
The short version (skipping all the math and reading) is it can take as low as two days to bruteforce one of these tokens, or simply enough observation of the application itself to deduce the key, no "wifi-sniffing" required.
The fun part, of course, is that one can root your box and use your own hardware against you, by distributing the task of cracking the key to your machine.

As such, my point still stands. It's a great idea, but not a method that'll prove any more "secure" for the user over time, given enough propagation of these devices and false security claims.
And I must credit the OP for acknowledging this to be the case outright.
