No nice way to do this.

One of my top three platform busters is a lack of relational list
support. Data entry  for this scenario  is really lousy. InfoPath can help
but the reason that you probably went with SharePoint is that the data
entry forms are dynamically created and maintained by the end user.

If nested  lists are not realistic, I am toying with a backup plan of
using the 'edit in datasheet' mode - with user filtering on a given
Widget - to simulate true nested lists. This would be our data  entry
form.

In order to make this workaround feasible, I need a mechanism  to create
an list  record for each Wackadoo for a given Widget - so my user doesn't
have to create  40 new items for each new widget.

Can workflow be used for this purpose? e.g. Enter a new widget in the
Widget list, and the 40 Wackadoos will be auto created - using the
Wackadoo list - in the Widget Wackadoo list.

There is this project out there, but I haven't seen much activity yet:
http://www.codeplex.com/SharePointSubTasks

I created a workflow that created several other items in different lists
using SharePoint designer. It was a pretty simple scenario  and,
therefore, a fairly simple solution.

Seriously, SharePoint lists  are not currently built to support
normalization and relationships. That's what you really want. The
easiest way to do this would be to write a set  of custom webparts that
talk to a back end relational database. I've done this on several
projects and although it requires a little coding it is much better than
trying to trick SharePoint into doing something that looks like its
relational when it isn't.

You've hit the nail on the head. What I really desire is a relational
model, with SP as my interface - a stopgap solution. My issue now isn't
so much how to store it relationally - I think I've got that figured out
in SP, kludge and all, - but how to make the user interface work like I
thought it could; As a grid. For someone with lots of data-modeling,
and some coding - vb, javascript 5+ yrs ago, what would 'a little
coding' entail, and might it - webparts - allow me to create  the entry
grid I desire? BTW, most likely db in this instance would have to be
Access.

I would suggest you to take a look at Bamboo Solution's list  Integrity web part.

store.bamboosolutions.com/...-part-release-20.aspx

Though not equal to relational entirely, this web part can build Primary
Key-Foreign Key relationship between 2 lists.

What you are suggesting is VERY doable; in fact, I don't understand why a much
larger proportion of Sharepoint solutions aren't built this way--as a collection
of web parts which address a separate relational database.

There are two issues here:

1) The philosophy: using a relational database for complex functionality, and
Sharepoint lists  for less complex functionality and integrating with specific
Sharepoint features. I would incline towards 80/20 for using a relational
database for any functionality that is sufficiently complex.

2) The logistics of coding web parts with all of the available ASP.NET controls
when a presentation layer isn't available. It's a bit of a learning curve at
first, but once learned, it is quite doable, and also, MUCH faster because the
entire web part is precompiled. You asked about GridView; below is a code sample
which binds a datasource to a GridView within a web part. I am showing a subset
of the code where I am grouping controls within a panel, in this case, a Label
followed by an SPGridView. Elsewhere in the code is the event handlers, etc.

Have a look at below link:
www.codeproject.com/KB/XML/NestedListSP.aspx

you can add Dataformwebpart to Edit, New and Disp forms of master/parent list.