This should not be a matter of if you connect to the site via the full URL (because you access your site remotely) or http://localhost (from the server, itself). To SPD, from what I've seen, accessing via the full URL has always worked for any operation, for me, and I've yet to find issues related to using that.
I also doubt anything has to do with the reg keys you edited, unless, from reading that MS KB article on why you might've done that, you really are trying to use only Basic authentication in IIS on a SharePoint site - which is really kind of whack, if you ask me.
There's no reason not to run Windows authentication on a web application running a SharePoint site, and it will make your life a lot easier. If there's a reason to use specific user names on a webform instead of a Windows log-in, that webform should be coded to proceed based on Forms authentication and use a completely different website under IIS than the SharePoint site you would be trying to connect with via SPD. Just best practices - you don't mix apples and oranges. But we digress, and that might not even be your set-up...
From what I've seen of this error, I've seen success in beating it one of two ways:
1) Delete the Task List associated with the workflow you cannot publish. Try to publish again - it should re-create that Task List. (reference link)
2) This worked for me: Create a new Site Workflow, save, attempt to publish. This did not immediately work - I closed the workflow, and I chose another Task List for it. I tried to publish again - this time it worked. Then I was able to create a new List Workflow, save, and publish to the same list I chose for the Site Workflow. Successful. Then I flipped the Task List back to the default that had previously failed for my Site Workflow. Successful.
So I would suggest playing around with the Task List that is selected. Perhaps it is too full, permissions incorrect, just corrupt and in need of deletion. The list really doesn't matter for historical purposes - it's just a dumping ground for SP.