Gave this some more thought and realized two things:
1) The scope/granularity of <jaxws:enableWrapperStyle> is a bit more complicated, according to the JAX-WS spec.
... when determining the value of the jaxws:enableWrapperStyle customization parameter for a
portType operation, binding declarations MUST be processed in the following order, according to the element
they pertain to: (1) the portType operation in question, (2) its parent portType, (3) the definitions element.
I guess to implement it right we'd need to do that, even though I'd guess it would be awhile before we'd ever come across a need for this.
2) I can see why you raised the subject of wsdlgen. There are some round-tripping issues here. If I start with a WSDL op that otherwise qualifies for wrapper-style mapping but has <jaxws:enableWrapperStyle> and generate Java I'll end up with a "bare" mapping and the Java will have:
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
However, I don't see that the JAX-WS spec says anything in the other direction, about mapping this (generated) Java to WSDL. So I might end up with an equivalent WSDL, but without the <jaxws:enableWrapperStyle> customization. The next person to generate Java might just then (assuming the toolset doesn't "remember somehow) get a wrapped-style Java interface.
Now... I still think it would help greatly to have a test to talk to before going further... but I thought it might be helpful to write down that thought after having it.
It might be that, after considering the second point, we need to take a completely different approach than simply reading in the <jaxws:enableWrapperStyle> customization like in Eric's patch, a modified version of which I used to pass the interface-wsdl test I added.