
Remember that the plugin will compile all your Scala sources first, which means you will not be able to reference Groovy classes (nor code placed on src/main) from your Scala code.
Back to the implementation details, Daniel points out that while Structural Types will solve the problem they carry a performance penalty, and that Traits would be a better solution. Traits can be seen as Java interfaces (though they actually do more than that) which back in Javaland are used to convey a contract, exactly what is needed in this case. Armed with that knowledge I happily added an Output trait into its own file, changed Greeter.greet()'s signature to take an instance of Output as parameter instead of the structural type, finally made the Model implement Output. I would be happy to say all this worked, sadly it didn't, perhaps I miss-configured something but the Scala compiler complained that setOutput was not a value on Output while the trait stayed on its own file, moving the trait definition to Greeter.scala solved that problem. The next one was the usage of the @BeanProperty annotation, when the Scala compiler sees that annotation it will generate the all-so-popular get/set pair for that particular bean property, unfortunately for Groovy, the compiler still generates the Scala required accessors (output_$eq() & output()) as it can be seen by decompiling the generated interface
This means implementing Output from the Groovy side would require providing an implementation for two more methods, ugh. Next tried changing Output to an abstract class as an alternative, and while the app compiled fine and ran it didn't pop up the dialog, meaning the event was getting lost somehow in the pipework

It occurred to me while writing this post that perhaps dropping to the common layer, Java the language, would also help. Scala has a joint compiler option similar to Groovy's, this means you could compile a version of Output as a Java interface along with the Scala code, then have the Groovy Model implement said interface.