Circling back...  Got it figured out, kinda.  Not working, but figured out.

Machinekey settings were correct; they must always follow the db contents/data.  This has not changed, and the keys had nothing to do with the inability to log in for this case...

I got time to poke around the post-migration db and found some serious issues in the DNN USERS table.  The aspnet tables were fine, but the DNN Users table was nearly totally blank [only a handful of records vs 500 expected and in the original].  Re-transferring just the data for that table alone cleared the login problem.  Other issues remain...

Other tables are likewise totally blank.  They were tables beginning with V or W and came after the Users table in the script 'data insert' section [very near the end of the 120,000 line script].  It was like the script just gave up and quit, yet it said it was complete, but with errors; I believe the SET IDENTITY_INSERT errors dealt with those tables...  Those errors did not occur when the identical section of script was executed alone, though, and the script does not appear to have been incorrect... [i.e. the error report was in error, but who knows w/o valid line numbers, SSMS sucks in that respect...].  [Disclaimer:  I'm not a programmer...]

My conclusion is that DNN is fine and Plesk is fine [I really like the collection of tools a lot], but that the 'script' migration process between db servers as a whole is fundamentally flawed.  I am not certain the results would be the same if I ran it again, identically.  Perhaps running it remotely is the problem; no ability to check for or correct errors in the result [the process is open-ended and obviously error-tolerant].

Migrating to GoDaddy Web/Plesk Hosting is highly NOT recommended at this time [scripting your db in is the only way to get it to the db servers as the Plesk 'upload' feature is off and appropriately so].  It would be my candidate of choice if I was starting anew with a client/site, though, mostly due to the superior Plesk tools.

I will try again in a few weeks or months; I may try breaking the script into pieces; I may not bother...

Bob

After 4+ weeks and countless attempts at scripts, import/exports, directly connecting db's and failed copy's, GoDaddy has acknowledged that an existing site with stored procedures, UDFs, and such [i.e., a non-trivial DNN install] cannot be migrated from their old servers to their new servers without effectively a rebuild of the db on their new server environment.  To get your local db to their new server environment the scripting that is part of SSMS [Management Studio] is to be used and their provided procedure.  The procedure yields highly inconsistent results [lost/missing data; sometimes complete tables lost].  The only consistency has been a failed migration. ZERO success in dozens of attempts.

They claimed the procedure works for them, so I tried it with a virgin DNN install of Awesome Cylces; no joy...

My quest began when I had to upgrade my hosting to run DNN 7.0.0 or later, only to find I could not take my db with me...

GoDaddy today issued the following response, which should scare the pants off any customer with an existing DNN site hosted there.

Support Staff Response

Dear Bob ,

Thank you for your response.

I understand you are having issues with the import of your .bak file. You can only restore a .bak file to the hosting account it was originally created with, if you make a backup of the .bak file in an alternate account, you are still not able to restore it by uploading it to an alternate account. To clarify you are able to install the Express version of SQL Server Management Studio to accomplish this task, you do not need to install the full version.

You will need to import the database to the local database that is installed with SQL Server Management Studio and then import it to the database on file. In our previous incident we explained that some features can not be migrated to alternate Shared Hosting environments, this would include Stored Procedures, Schemas, Triggers, etc. If these are a part of your existing site they will need to be recreated in a Shared Environment database on the new hosting account.

At this time Classic Hosting is no longer offered in the hosting environment as this is an outdated technology and we are working to have customers upgrade to the latest versions of software. The ability to import a .bak file with the additional features is possible but for this type of access you would need to obtain a Virtual Dedicated Server as you are granted more access to use more features.

Please let us know if we can assist you in any other way.

Regards,
Brandon P.
Professional Hosting Services

I believe GoDaddy will see the error in their logic since I cannot afford to rebuild, or a VDS.  Perhaps others will conclude similarly.