The idea is to embed the unicorn and mongoid config files into the applications. They would be checked into source control but they would respond to a small set of environment variables such as PORT and MONGODB_URL rather than having such config data hardcoded into them. The unicorn config is plain old Ruby while the mongoid config is ERb which compiles to YAML: both can be written to look at environment variables. Here's an example of a config/database.yml written to look at the DATABASE_URL environment variable: https://github.com/heroku/heroku-buildpack-ruby/blob/v63/lib/language_pack/ruby.rb#L503-L555. Every Rails application deployed to Heroku is automatically configured to work with that config/database.yml.
Your Chef code would be responsible for having a way to specify a set of config vars that would be exposed to the application as environment variables, and for causing the application to be started with those config vars exposed as environment variables at application boot. Your chef code would no longer need to keep track of full unicorn and mongoid config files.
Each application would be responsible for documenting which environment variables it looks for and how they are used, and when deploying the application, setting up the right config vars.