Maybe I'm missing something here, but if the password is being checked on a remote system, then the variance in network transfer time is going to far, far (by many orders of magnitude) outstrip the difference in time a CPU takes to compare a few characters in a string.
Also, this shouldn't even be a source of information if the password is salted and hashed to a fixed length before storing. I'd hope any secure system was at least doing this to start with anyway.
Surprisingly, with sufficient samples you can filter out the jitter that comes with transit time, and still execute a timing attack. From the abstract:
Our work analyzes the limits of attacks based on accurately measuring network response times and jitter over a local network and across the Internet. We present the design of filters to significantly reduce the effects of jitter, allowing an attacker to measure events with 15-100µs accuracy across the Internet, and as good as 100ns over a local network.
With the paper available at [1]. Nate Lawson and Tyler Nelson also did a Black Hat presentation on remote timing attacks ([2] and [3]). Bottom line is that if you're interested in using a timing attack, and you've got some effort to throw at the problem, remote ones are feasible.
That's my thought too. If you're susceptible to this kind of attack the problem is the lack of basic salting + hashing to create a fixed length password.
Also, this shouldn't even be a source of information if the password is salted and hashed to a fixed length before storing. I'd hope any secure system was at least doing this to start with anyway.