Jmknapp,
Thanks for your help!
You're logic seems sound. The Arduino has a relatively large read buffer (for now we're assuming the write buffer is shared) so we figure we did sit at around 40 characters with all of our commands per frame, but those should be getting cleared out pretty fast, so it would take a great deal of return processing to fill up that buffer. This was why we originally didn't think we would need to clear out the buffer in between loops. But having read your suggestion, it made sense to clear the buffer anyways just to be safe. Thanks again.
We think the Vdrive has its own buffer, and this is what is getting bogged down. While it might be capable of writing speeds up too 3 million baud, we don't think the host controller is capable of understanding commands at that speed. It is getting bogged down probably in some form of an internal buffer.
It seems like “opw” and “clf” commands make life difficult, so instead of writing many files we are now writing one file per a recording session. Also, we broke up the actual write process with delays. So we now have a good beat on what's going on, though we are still uncertain on where things bottle neck.
We've figured out that in order to write successfully, the size of the delays need to be adjusted in proportion to the run time of the app (or the Vdrive will stop writing).
We just had our first good write session. This version of the code ran for around 10 min's at 5 frames a second. This is still too slow for animation purposes, but its a start!
The code is cleaned up a bit and should work if someone was to dare this feat at home 
Please see the next post for the working code.
Thanks!
Carlo and Don