Thought about this one for a while. Changing the routing tables with a simple batch file is pretty easy. The 'route' command can do everthing. Problem here is extracting the existing configuration, ip's, LAN connectons, existing gateways, etc. Those things aren't provided in variables that can be accesses in a command shell script.
I think what you are wanting to do could be done in Visual C++, or Visual Basic for that matter using API calls. Haven't entirely thought it through, but it will be on my mind for a while.
Having said that, I think the spirit of what you want to do can be carried out fairly easily. As long as the user doesn't check that stupid box on the network connection for the VPN that says 'use default route on remote gateway' or something like that, and they leave the box marked on their network connection for their ISP, you shouldn't see internet traffic across your VPN. Adding the route to allow access to the other VPN clients should not be to bad, something like 'ROUTE ADD 192.168.20.0 MASK 255.255.255.0 192.168.20.XXX', replacing the xxx with the VPN client ip. Seems to me that there is a way to execute that after the connection is made, but not sure about how to come up with the ip. I would probably assign a static ip from the VPN pool to each machine and make the route persistent (add -P to the end of the command) just to simplify things.
Once that is done, you still have the problem of keeping the internet traffic off of your VPN. I would setup an iptables firewall on the linux box, if you haven't already. When the VPN connection is created, a virtual interface is created on the linux box. You could setup a few rules for the firewall, basically any traffic coming from the ppp0 interface should be checked as follows:
Originating from addresses other than those assigned to your VPN -- drop
(that's a good idea anyway, if someone does manage to trick one of your clients into routing traffic back to your VPN server, it would make it a little harder for them to do real damage)
Destined for anything other than your VPN addresses (or your LAN, if you're allowing access there as well) -- reject
This would solve the problem of using your bandwidth for the most part. If a client does try to route internet traffice through you, the initial connection would be refused, probably even the DNS lookup unless it is cached locally. Shouldn't make too much traffic. Your users will complain, and you can walk them through enabling the default route on their main connection.
Destined for one of your VPN addresses -- forward
Again, not the perfect answer, but I'm still thinking on something better. Hope some of this makes sense, it is late here. If any of this is of interest and you need a better explaination, post back. I'll be watching.