Dynamic reconfigure does not handle arbitrary parameters. It requires a ROS node to provide the required reconfigure server interface.
The easy solution is to define a node whose only job is to provide a dynamic reconfigure server for the common parameters. That can easily be done in Python.
In your example, that parameter node could be called base_controller.
EDIT:
Understanding your goals better now, I see that my initial answer does not meet your needs.
Dynamic reconfigure is a good tool for configuring a single node, it provides:
A callback to the node when any parameters change. All of them are supplied initially. There is no need to poll the parameter server periodically, which could easily load down the server.
Optional limits on parameter values, and a way to run sanity checks on parameter updates, rejecting changes considered invalid.
A simple automatically-generated GUI client for changing the parameters.
Keeping changed values up-to-date in the parameter server.
I don't see any reasonable way do all that for your use case. But perhaps you don't need all of it.
Assuming you want to notify more than one node when a parameter changes, you can use getParamCached() in C++ to periodically update each interested node's copy of a shared parameter without pounding the parameter server senseless.
Unfortunately, there is no similar function in rospy. If Python clients need access you'd have to provide a cached update service similar to that provided by roscpp. Not trivial, but generally useful.
If you want a GUI for updating the values, you'd probably need to write a custom implementation, which could be done quite well in Python. Take a look at rqt, which provides a nice Qt plugin interface. That interface might also validate parameter values, where appropriate.
Maybe others will provide some better ideas.
EDIT 2:
Your idea of publishing all the relevant parameters in a topic is easily done. Its main drawback is the effect on the modularity of your system.
Keeping knowledge of private parameters inside a single node makes it easy to reuse in a different context. So, I recommend keeping most parameters private.
That leaves a small number of truly "shared" parameters used by multiple nodes. I recommend grouping them into somewhat larger components, maybe per-stack, each with its own topic message. That way, other parts of the system would remain independent of changes to parameters they don't care about.
