That's a super interesting question. I can't speak for the product team and the roadmap - even if I could, I am doubtful they'd put any commitment in writing here 😉
The wrinkle here is that many deployments actually do want to have control over data ingestion so as not to compromise their license. Imagine if one of your users added a datasource that turned out to be sending a ton of data into your Splunk environment resulting in license violations - you wouldn't know until it was a problem. Another challenge is that some data is harder for Splunk to auto-determine things like event breaks and time stamps. Therefore, many admins prefer to define those details before data ingest begins so as to make the indexers perform as effectively as possible.
That said, the REST Api is pretty awesome and can be used for doing a lot. You could probably create a new monitor input on the forwarder using the REST API (http://docs.splunk.com/Documentation/Splunk/latest/RESTREF/RESTinput#data.2Finputs.2Fmonitor) but then it wouldn't be managed by the deployment server. Alternatively, you could use the REST API to create a serverclass on the deployment server (http://docs.splunk.com/Documentation/Splunk/latest/RESTREF/RESTdeploy#deployment.2Fserver.2Fservercl...) and have it reference an app that your solution automatically created and staged on the same deployment server.
Lastly, remember that the configuration in this context is all flat files and therefore could be generated with a shell script on the deployment server.
But other than that, there is nothing currently available to automate that for you.
