Adding complexity to the interaction does not help the user's work flow for a limited use case. TL;DR: Don't flip between check boxes and radio buttons. Doing so just adds unnecessary controls and complexity.
Understand the work flow.
Don't just think about all the possible interaction scenarios and come up with a solution. Understand the user's actual work flow and design for that. If the user needs to select multiple options on a regular basis, that's the dominant work flow.
Use the proper metaphors.
Use the control the illustrates the potential interactions. Checkboxes are a widely understood metaphor that allow for single or multiple selection. Users get this. When they see this, they know what they can do:
download bmml source – Wireframes created with Balsamiq Mockups
If you present them with radio buttons, the user understands what they can and can't do. The radio button metaphor is known for single selection. So now you're adding a situation where a button totally flips the active metaphor the user is familiar with.
download bmml source
Avoid Modes when possible
When you introduce modes to a user interface you increase the possibility of confusion and error. If the mode switch is not brilliantly obvious it can be lost amongst the other controls and a user can fail to notice the state they are in.
Why can't I select more than one? How did I get here? How do I get back?
Modes can be necessary in certain situations, but should be avoided otherwise.
Don't make the users wonder what will happen next.
- What happens when the user hits this button with multiple checkboxes selected?
- What happens if I immediately hit the button again, do I get my selections back?
- When the radio buttons are visible, why can't a select more than one... I have to find that trigger to let me do what I want.
- Why do I have so many options laid out in front of me?
- Why the heck do I have to "explore" to figure these all out in the first place!?
Don't be a helicopter designer
If you try to coddle to every possible interaction, you will overcomplicate the interaction for every interaction. Use the interaction that best fits your primary workflow, while still supporting other interactions.
Wait a second... what's up with those last two bullet points above?
To point 4: 20 checkboxes is a lot of options to push in the user's face. An alternative pattern might be a better choice.
To point 5: Why doesn't the user already understand what the options do? If the user "almost surely... will eventually reach a point where they want to experiment with a single data source at a time" then something is likely wrong with how those data sources are being presented.
The interface should not hide meaning. If I select a checkbox, I should know exactly what is going to happen when I do!
Okay, sure... there are scenarios where exploration makes sense. Not being familiar with exactly what is happening with these checkboxes, that may be the case here. But be sure you're not using the idea of "exploration" as "just let the user figure it out so we don't have to."