CRUD-driven apps are in my experience a UI disaster.
The display of the UI isn't a function of CRUD-drivenness. All apps are CRUD. Most UI's today are rehashes of character graphics tools like Professional BASIC (and the 3270 long before). The widgets are still pixelated analogs of, well analog, car radio interfaces and Chinese restaurants. Radio sets, check boxes, lists, menus; there are even Dashboards with pixelated knobs and dials, for crying out loud. The sad fact is, there isn't much that's new in business/PC based software. Some of the devices from Apple have implemented new-ish gadgets, but those devices (yet) aren't integrated into business software. The iPad is likely to be the first; although tablets, per se, have been used in warehouse/distribution VAR systems for decades.
Some object that generated CRUD means: BCNF datastores with limited data per interaction, rather than the flood of hundreds of "fields" which replicate the un-normalized messes so beloved by java/C#/VB coders (and COBOL/VSAM forebears; this genealogy mostly unknown to contemporary coders). Phones/Pads will demand more parsimonious data structures in order for applications to succeed; no keyboard and such.
What form the UI takes is dependent on the generator, only; not the schema. It could be VB or html/js/AJAX or iPad or foobar, for all that it matters. BCNF datastores offer *more* flexibility in the display of data than the un-normalized alternatives; since the datastore is by definition fully disaggregated, the UI has the option of aggregating back to whatever level of mess the users demand. They will never know the difference, only that shipping inconsistent data is well nigh impossible.
We need to keep a number of distinctions in mind: the discipline of RAP, the discipline of BCNF/5NF, data logic rather than code logic, server-side rather than client-side control, the UI. There are synergies and antagonisms at work here.