As I understand it, the SecurID tokens don't use a "rolling counter" — the token is generated solely from the device serial and the current time. Also: in the RSA SecurID tokens I've seen (admittedly limited), the user doesn't press a button to generate the token; instead the token is constantly visible on the screen. Thus the token generated doesn't get out of sync (in the sequence) with the server, except for the possibility of clock drift on the token side (usually servers use NTP and so their clock drift is negligible).
However, the typical solution for clock drift problems is to store a "drift" parameter on the server, on a per-token basis. This drift parameter can be updated manually (for maximal security but also maximal pain) or one can check the surrounding intervals on the server side. For example, if I log in now, you might check the server's current sixty-second interval, the previous one, and the next one all for validity, and if the previous/next are valid, you store that drift for the token.
On the other hand, there is an algorithm that suffers from the problem you've described: the HMAC-based One-time Password Algorithm. It uses a rolling counter that is supposed to be synchronized on both the server and the token. So, if you have a HOTP-based authenticator and you press the token generate button many times, you will cause it to fall out of sync, and manual intervention is required by the server administrator.
A similar solution can be enacted as above: check the next few values of the counter, say counter+1, counter+2, counter+3, etc., and store that as a 'drift' parameter. Depending on how far out one checks, the token could eventually go out of sync, if it were pressed repeatedly.
A variant of HOTP that fixes is the problem is the time-baesd version, which uses a "time counter" instead of a real counter. This is what Google Authenticator uses. Here, you still have the clock drift problem, with the same solution as above.
