Having said that, TDD does work "best" for new development, and many VFP devs are not doing a ton of apps from scratch which is why it may not have caught on. It also works best with logic that's not buried in the UI, and unfortunately a lot of us buried it there (forgive me father).
We have used FoxUnit for our FoxPro DOS based application. That program was certainly not written with unit tests or even classes in mind. But even a procedure with private variables can be a testable unit if you design the interface carefully.
It doesn't make sense to retrospectively create unit test for an existing application, I agree. However, when you modify existing code it's often possible to move the parts that you need to change out of the SCX Click or whatever method into a separate class. There is no need to do this all at once, just when you need to make changes to code anyway.
When code uses functions like MESSAGEBOX(), etc. you can replace those with a simple messagebox or dialog class (such as the one in INTL) and then in your test mock this class. Various tests can then cover multiple paths through the code depending on a simulated choice a user made. You can also assert that certain messages are shown to the user by making a call an expectation in foxmock and then verify those afterwards.