If the source machines are connecting via a NAT router then standard IPsec VPN's wont work - the ESP protocol used by IPsec doesn't play friendly with NAT's as they use port remapping and ESP doesn't have a concept of ports. An L2TP\IPsec VPN can tunnel multiple concurrent clients through a NAT because it encapsulates the IPSec payload inside a UDP tunnel which does play nicely with NAT environments.
The only thing needed for static IP assignment from DHCP is the MAC address. The other items must be there for administrative convenience. I have found it easier to use Excel or a wiki page, "hard code" the static devices, and take the static IP ranges out of the DHCP pool.
Now, there is no convenient way to have a "primary" and "backup" DHCP servers, particularly with low end gear. I don't think it will work as you are expecting, and you will see random confusion in IP addresses.
It also looks like you are over-thinking the IP protocol, pre-assigning too many statics and leaving the DHCP space too small. Are you really going to have 126 fixed IP devices? I would have 1-60 set as fixed, 61-254 on DHCP. Having a DHCP server with no free addresses is a tough problem to fix on the fly.
My suggestion is to put the wireless devices on a separate subnet and have the WRT54G serve DHCP and do NAT. An alternative is to have the RV082 be the DHCP server and have the WRT54G proxy DHCP requests and not do it's own DHCP.
Best Answer
According to Cisco's support website, the answer is no. To confirm I have deleted all client to gateway tunnels and was able to successfully get QuickVPN to work. The following image from Cisco's support page shows one QuickVPN link active under the VPN Client Status and no tunnels defined under Tunnel Status: