I like the Services idea. Django's settings file is the weakest link in the framework. It's easy to roll your own settings apps if all you need to configure is your own code. But that just makes things more complicated when you are integrating other apps.
I've tried a few different apps designed to move settings into the database. None of them have worked very well. This area of Django is still ripe for some killer app to become a defacto standard.
It's less painful if you invert those files. For example, create settings/defaults.py, then in settings/dev.py, import * from defaults and override what you need to. Set DJANGO_SETTINGS_MODULE appropriately. You'll thank me when you're adding dev-only apps, middlewares, etc. and can say INSTALLED_APPS = INSTALLED_APPS + [...].
I already do that. I have a common_settings.py, a dev_settings.py, and a local_settings.py. That's not really the use case I am speaking of.
First, it still makes you put all application config into a single config file (considering that even if you "inherit" settings from a common file, it's 100% equivalent to having one big settings file).
Second, you cannot change these settings in-app. They are hard-coded.
If it's not already supported, it shouldn't be difficult to make a Django process respond to the HUP signal by reloading it's settings. That's how Postgres does it.
I've tried a few different apps designed to move settings into the database. None of them have worked very well. This area of Django is still ripe for some killer app to become a defacto standard.