Short answer: do not select any radio button. Leave them all unselected.
However:
- This is a misuse of radio button control where (by convention) there always should be one (and only one) selected item.
- Unselecting all items is not noisy (IMO) and recall same pattern used in other controls (for example combo boxes) where no selection means multiple selection. This is a benefit but it's also a drawback (the same you have for combos): it's almost impossible to have a no selection state (for example to distinguish a state where user didn't select anything); to avoid this you may consider what the other answer says. Note that this is a bad usage for radio buttons, if it's what you need then you should use another control.
Controversial answer:
DO NOT USE A THIRD/MIXED STATE.
The other answers address radio button issues (one of them even attempting to unify checkbox and radio visual model). It's a model already in use on some OSX applications and default Gnome theme then it won't astonish many users (with visual style variations it's in use from 1980s in Motif widget toolkit).
However...
For each control of your user interface you have a different interaction model. Users will need to learn something different multiple times:
- For text boxes you have a special placeholder text: you use text itself to clarify content (using styles to highlight it's not an user input). It works but it's not perfect and users should learn this behavior (if they don't know yet). It also adds noise to your UI.
- For checkboxes you have a third state, if they aren't other checkboxes it may not be clear if it's checked or indeterminate/mixed.
- For radio buttons you do not select anything but it breaks a common convention: radio buttons have always one selected item. Moreover is it unspecified or indeterminate?
- For sliders and knobs...you don't have an option (at least nothing I can think about).
- For lists and combos you may use something similar to text input.
- And so on...
In my opinion, even if it's common and well-accepted (or tolerated?) we're asking too much to our users. It's a reminiscence of old days we're still sticking with. It's a simplification (both for old days UI designers and programmers) we no longer need.
What to do? I have to admit I don't have an answer that really convinces me. What I have is a compromise I use when I want to avoid any ambiguity (think, for example, users entering medical records: too much data, too much work, too little time...errors).
In this cases (unless my audience are other programmers then used to this kind of incoherent abstractions) I prefer to do not show original control but something else, an explicit user action will change it back to right control. Eventually you may pre-select most common value (but also pre-selection is controversial, I'd use it only for coherence).
Note that this UI example is just...an example. What' I'm trying to express is the concept; I'm a programmer then a better UI designer may make it pretty and well integrated in existing UI. Probably a small subtle transition from this control to expanded inputs may also help.
Note that same control may be used for every type of input. Text is pretty important in this case: it has to clearly communicate that there are multiple values for an existing field (it's not a common pattern then users have to learn) and, if there is not a label, also describe which field will be changed.
As last option you may even consider to replace radios with combos (where a multiple selection state can be clearly communicated):
