We use something close to this model, but there's no need to create separate Jenkins jobs for each branch.
We have a single job that takes the git branch as a parameter and can run all of the automated tests (and other jobs for builds, etc.). There is a script that watches for new pull requests and automatically triggers the Jenkins job to run all the tests on that pull request to verify that they pass before the reviewer merges in to master.
We have 5 QA servers and a dashboard where the tester can point any of the QA servers to a feature branch. Works awesomely.
From what I can tell, this just makes it easy to run tests in branches. My team uses something similar that kicks off a build whenever someone comments "build it" in a GitHub pull request, and posts the results to the pull request discussion.
Also, feature branch development is just how we're using it. The code monitors git for any new branches and automatically clones jobs for new branches. This would support a more traditional master branch with release branches created periodically. Those release branches would automatically get Jenkins jobs created for them instead of someone manually having to do it.
This project was presented at a user meeting tonight and one of the attendees there was planning on adding Mercurial support.
http://about.travis-ci.org/docs/user/build-configuration/
Basically, it builds whichever branch you push, as long as that branch has a config. I think this is better because your config is in SCM instead of off in jenkins-land (even though it is highly travis-specific).
Unless of course, everyone gets a notification for every build in every branch. Then you'll have practically every developer in your organization hating this feature! I'm sure Jenkins has a way of controlling that though.
[1] https://github.com/gvalkov/jenkins-autojobs
[2] https://github.com/gvalkov/jenkins-autojobs/blob/master/doc/...
