For "as fast as possible", I'd
- Rewrite your sampling code in assembly language (just those two statements, not the whole program); and
- Buffer the raw data pairs in memory if you have enough of it, then store it to the card after the measurement burst. If you need more data space, consider that the timing of a tight assembly loop will be consistent (and fast!) and can be measured. You may not need to read the clock at all. Note that you can get the same timing consistency using C/C++ if you read the analog and clock ports directly, and maybe as fast. It's just that with assembly language, WYWIWYG (what you write is what you get); the compilers' code-generators and optimizers won't mess with it.
A possible issue with your code as you've written it is that writeData probably buffers the data on most calls, but whenever a call results in a full buffer, writes the whole buffer to the card, introducing jitter into your sampling.
Addressing your edit of June 3, 2014, "I would like to record the exact time that the analogRead data was collected":
Since you proposed using micros() (as opposed to a real-time clock), I assume you are satisfied with the relative time. Once you know your data collection code is completely predictable, then the offset from reading data to reading time is constant, and since we're using relative time anyway, can be discounted, or at least, corrected for.
It isn't completely predictable of course, since in this case, you're using an interrupt-maintained clock, and can expect that sometimes the interrupt will occur between the data read and the clock read, stretching the offset for that tuple. To get even more accurate, you'd need to keep interrupts off, read the timer yourself in an invariant way. f/ex, you might run the timer at such a rate that you could expect to take two or more samples between overflows of the low-order byte, read and store only the low order byte as your time sample, and post process the time data to reconstruct the high order byte by detecting wrap-around in the low-order.
With no interrupts running, and once you know the rate at which you can sample data without reading the clock, you could read and save the clock once immediately prior to taking the first sample, and infer the times of each subsequent sample based on the known sample rate.