Create an app for all systems that will be getting their configurations from the Deployment server and put the outputs.conf file in the apps local directory. Example: CORP_APP/local/outputs.conf. You're outputs.conf file will need to have the configuration correct to where it is sending the data to. For the inputs.conf use the same method as you did for your outputs. Example: if you are looking for web logs on an apache server then CORP_APACHE/local/inputs.conf and set up your settings there. You can then apply the CORP_APACHE app to the apache servers in your environment.
The host is set up on the forwarder when it is installed. If this system is a syslog server and you have properly set up your syslog server to log each host differently then you can use the different techniques for the host name location in the file location. There is plenty of documentation on this.
At this time there is no official way to update the UF from the Deployment server. This does not mean that you can not set up an app that has a script in it to check a version and if different run an upgrade, this is basically the same as a scripted install with a little more to check the version.
It doesn't need to be in system/local to be a config. Splunk silently merges all of the configuration data into a master version of the config at runtime. It seeds with system/default, collates application defaults, then application overrides (from local/), then finally system/local.
To push inputs.conf and outputs.conf to the forwarders, simply include them in an application directory that you serve up via deployment server.
You can't write to system/local via deployment server, so the inputs.conf with host=xxxxxxx in that forwarder's system/local will still be present, and "trump" any other settings to end up in the working version of inputs.conf. In other words, "don't worry about setting host".