I have managed a similar network, less the number of laptops (we only had a few). One important break you need to make is that you should not give root to your clients. I may seam convenient for you and them at times but it inevitably leads to users breaking there own systems in ways you could never imagine. If they need limited root use sudo.
As for your remote X install you may be better off exporting a more complete /usr/local dir structure. By this I mean install all the applications core to your env on a remote nfs server and
export that dir. The clients would only need a minimal install set and the rest of there apps would
be exported from /usr/local. This has many advantages as it provides a single point of upgrade/configuration for all the desktop clients, simply upgrade the server. The application set on /usr/local should include, the standard desktop (gnome,kde), and any office apps, in your case wine of corssover office. For the standard office apps, Word and Excel, you should be able to get away with using wine so don't pay for crossover.
Also it is very difficult to gage your needs when exporting complete X sessions, you can't control the number of apps your clients open and there for it is very difficult to gage memory and CPU needs. It is one thing to export X to some thin client with slim window managers (xfce, fvwm) that only run an instance of mozilla, your clients will be running a full KDE or Gnome, Office apps mutiple instances of wine/cossover office, and mozilla all big memory/cpu hogs.
We found that we rarely need to edit the clients local etc dir. Once we worked out all the kiniks for each desktop we saved that etc, and wrote a post install script to complete the install., i.e. hostname settings. We also ran an LDAP serve as our NIS provider, and had fairly complete, skel for the users home dir's which configured most of the apps with user specific config options, like mail, you would also need a .wine in the skel.
Another useful tool we used to install apps was stow. This is a GNU package management system that allows multiple instance of an app to be available at any given time. The way it works is when you build and app from source, as we did with almost all of our apps, we set the install prefix to /usr/local/package-version then you used stow to makes sim-links from the package-version dir to /usr/local . This allowed us to easily upgrade apps in place and if we made a config mistake we could simply unstow the bad app and restow the old app. This system could help with your laptops as you could simply tar up the stow dir drop it on the laptops and stow all the packages. Using some startup scripts you could, as the other post suggested use rsync to update the stow dir and stow any package changes.
These are some of the things we went through. I tried to touch on as many things as possible, its difficult to get into too much detail though, I would be writing all night!! If you have any more questions just post here, linuxquestions is a great resource.
NIS-LAP and Pam-LDAP packages and conversion tools
Build Gnome from source