I think this ends up being one of those "if you build it..." things. This would be fairly easy to configure with existing tech:

1. Setup all of your desktops with an ssh key exchange auth account that would act as the equivalent of the usual slew of Microsoft service accounts (SYSTEM, Network Service, etc). This would preferably be in the deployment image but could be scripted after the fact.

2. On a master deployment server, have a separated set of configuration directories (/etc, /home/.$whatever to be added to /etc/skel and to existing users) and modify them to suit. A nice little gui with configuration options that hide the configs could be a plus for folks who aren't aware of every option available in a config file. At some point apps could distribute something like a policy-config.xml that could map config file options to policy options in the gui app to ease this.

3. A little scripting duct tape with rsync/scp and the service account could deploy the configurations. Writing an app to do this sort of thing would probably be better, but when you're not a programmer you work with what you've got.

4. Don't give users root. sudo configs could be deployed just like any other policy as needed.

The application deployment stuff is doable now with yum, apt-get, emerge, etc (we built one for rhel 3 using nothing but apt for rpm, rsync and perl in an afternoon a couple years ago, and we're not particularily good with perl). Configured correctly it ends up just like SMS or something similar (client checks in on a schedule, pulls "approved" apps down and installs in the background). From there it's probably not even terribly tricky to be able to do software inventories and tracking.

So really, I think all it would take is someone with the time, skill and desire to piece it all together - sooner or later it's bound to happen.