As a prototype, I skipped the part about on-demand copying from the remote system and just copied the files I wanted to play with up front. I then wrote a short shell script that scans for changes once a second and propagates them to the remote system via rsync.
This seems to work for the one use-case I've tried so far -- editing a script and seeing if the changes propagated quickly and accurately (they did). What I'm not sure is if the plan to ignore updates on the remote end will pan out.
Let me expand a bit on why I want this: I want to use my Lispworks editor for as much of my editing as possible. I also want to use Lispworks itself for as much scripting as possible, including scripting for work. Given that the work machine is two hops away (one hop to my work laptop, another hop (over a vpn) to the system itself), I needed a way to make the filesystem accesses a lot faster. (If I had a faster network I'd just use sshfs, as I briefly discussed earlier.)
So now, with a bit of preparation (the up front copying I mentioned), I can edit files locally (or process them with Lisp) and have saved changes propagate in 1-2 seconds.
Now that I have that, I wonder: will it do me any good? That is, it occurs to me: if I'm editing locally, and scripting locally, why do I care if the updates back to the work server happen quickly? I could just copy over here in the morning, and copy back in the evening. We'll see. :)