I may be getting myself confused here, but there's a couple of items worth considering. First, of course is that just because radio buttons have only on/off settings doesn't mean that they're binary data type interfaces. You can, after all, set up for example
three buttons in a group. Say ABORT, RETRY, CANCEL. The setter for the group's value would then be invoked with the enum value for whichever of the three radio buttons had been clicked to the ON position. Which is why you can't tie a binary-argument setter directly to a radio button. JSF is rather strict about such things - I've had grief with checkboxes for much the same reason.
So much for the presentation side. On the persistence side there's also room for trouble. Unfortunately, many databases don't support a native boolean datatype, so people have to fake it with character or integer fields with values like "Y/N", "T/F", "0/1" and so forth. Since there's no standard, there's no Java-level support, although if you're using an ORM, you may be able to configure in a data converter or conversion rule (which is usually called an "enumeration" value, even when it really isn't).
Stuff like this makes it a nuisance to try and present the actual ORM record directly to the UI. I usually end up putting a decorator/façade in front of the actual record. Or you can simply write an independent property and bounce its value through to the record, converting from enum to boolean as you do so.
When converting enumerations to/from numeric and
string representations, don't forget that enum has a number of convenience methods such as the ordinal() function.