One for, one against. :-)
At first I avoided the propertyeditor because I was probably going to end up needing quite a few, and wiring them all up with their application facade reference sounded tedious. But then I created a constructor that sets up that reference, and it was easy to pass it from the controller to the editor when setting it in initBinder:
So that seemed rather nice. The bean spec seems to imply that the as the most recent poster says, that the representations should be completely convertible from one format to another, which is why I was afraid it was bending it too far. Although the string in question is a logical, user exposed key field so it should always return a full photographer (or nothing if that photographer doens't exist; I suspect that's where the problem likes; I get the impression property editors aren't really supposed to have a lot of failure modes).
binder.registerCustomEditor(Photographer.class, null, new PhotographerEditor(imageApplication));
Of course, half the bean spec talks about graphic editing of bean properties and linkages to the AWT, so maybe it's not all that relevant anymore...
This form is complicated enough that I think I might just implement a dedicated command object for it and fix everything up in the controller, but that still feels more struts-like than spring-like.