Well, you could use practically anything to generate code in Forge, of course, within reason and as long as it works
Currently, Metawidget is used in the Faces scaffolding to inspect JPA entities and eventually generate various artifacts (including Java classes) in conjunction with a Freemarker template. Note that this is how the Faces scaffolding worked in Forge 1, and like you've found out there are limitations on how much users can control and customize the output, partly because this lifecycle does not allow you to supply your own code generation logic.
Since Forge scaffold providers can be written in a free-form manner, you're not bound to using this lifecycle and you can write your own. I would recommend you to take a look at the Forge 2 AngularJS addon currently developed here - forge/angularjs-addon · GitHub. It is being ported from the Forge 1 AngularJS plugin which supported more extended customization of generated code since you could supply your own templates. It still uses Metawidget, but mostly to inspect JPA entities and obtain inspection results to further drive a Freemarker template-based code generator. Users could supply their own templates as part of the project being scaffolded. Note - this template-based customization feature is not ported completely to Forge 2, but it should be out when the 2.0.0.Final version of this addon is released.
The generation model still has limitations on how much customization you can do (like whether you can generate additional files, not just the ones defined in the scaffold), and we're continuing to work on that.
So, you could write your own scaffold provider using these principles. This would be recommended if you need to bring in your own technology stack with vast changes to the generated code.
If you're looking to improvements in the Faces scaffolding like the ones described in the AngularJS one, you would wait until the Faces one is rewritten using these principles; contributions are of course very much welcome and appreciated.