You can add the following event handler to the Click event of each of the three RadioButtons (of which the Checked properties are bound to Application Settings) in your GroupBox:
Private Sub RadioButton_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles tomRadioButton.Click, dickRadioButton.Click, harryRadioButton.Click
    If sender.Checked = False Then
        sender.Checked = True
    End If
End Sub
It works, even though it takes a half-second for an unckecked RadioButton to be checked after you click it.
The reason for the problem was explained two years ago (in 2008) in section 5 of the Surviving WinForms Databinding post on the Turbulent Intelect blog (Thank you, ohadsc, for the link):
  Rule 5: Don't bind to clickable Radio Buttons
  
  I know how great it would be if you
  could just bind your bunch of radio
  buttons to an enum property. I really
  do. You think you're just going to
  hook up some Format and Parse events
  to translate back to your enum, and
  all will be well. It would be so darn
  convenient, if it actually worked. But
  WinForms just isn't cut out for this.
  For 3 full releases now (or is it 3.5
  releases?), this has been the case.
  It's because of the event order, which
  is not something that MS can go
  switching up without causing thousands
  of developers to get really cheesed
  off.
  
  The problem really comes down to the
  fact that unlike other controls' data
  properties, the Checked property of a
  radio button doesn't actually change
  until focus leaves the radio button.
  And as with all WinForms controls the
  focus doesn't actually leave the radio
  button until after focus is given to
  another control, and in fact not until
  after the Click event of the newly
  focused control has fired. The result
  of this, as it pertains to radio
  buttons, is that if you try to bind to
  them, the bound properties in your
  datasource will actually lag your
  radio buttons' visual state by one
  click. If you have just two radio
  buttons, the datasource will be
  exactly opposite the visible state,
  until you click somewhere else that
  doesn't trigger an action that
  references those datasource
  properties. Which can make this a
  really infuriating bug to track down.
  I almost thought I was hallucinating.
  
  Now, in all honesty, it's possible to
  make it work. But it is the kludgiest
  kludge that ever kludged. Okay maybe
  it's not that bad... but it's a messy
  hack for sure. It takes a lot of work
  for something that really should
  already be available. As near as I can
  tell, the only way to solve this
  problem without giving up the
  databinding mechanism is to
  essentially make your own RadioButton
  control, with a property change and
  event order that is actually useful.
  You can either write one from scratch,
  or sub-class RadioButton and override
  all the event logic with custom
  message handling.