The resolution to this problem is to call the cspack utility manually.  To do this, you should open a Windows Azure SDK Command Prompt window, then navigate to your project.  The default directory that the Visual Studio extension will use is the debug\bin\Publish folder in your deployment project.  You can use this folder, or any other folder you wish.  Simply call cspack with the filename of your .csdef file, and specify the roles using the /role: switch and the output folder using the /out: folder.

I typically create a command line file for my project to automate this.  For convention (and the hope that this is just a temporary thing until the next CTP), I use the debug\bin\Publish folder as the destination folder.  My command file also copie the ServiceConfiguration.cscfg file to the publish folder.  This process then eliminates the requirement to hit the 'Publish' menu option in the deployment project.

Wow, the blogosphere is fast.  No sooner than I published this article, than a followup article with better insight into the problem was published by Jim Nakashima.  I guess the root of my problem was the size of the package and not the complexity of the DLL that I was referencing.  My packages are approaching about 20MB, and when I was isolating this with an empty website, simply adding a reference to our CMS project was enough to surface this bug.  I am happy that the problem has been identified because that means it will be fixed in the next CTP.  I am happy that there is a workaround for now using the cspack command line.  Here is the followup article: http://blogs.msdn.com/jnak/archive/2008/11/14/visual-studio-publish-of-a-large-windows-azure-cloud-service-may-fail.aspx

The January CTP has resolved this bug and I no longer have any problems with my Azure solutions not publishing within the Visual Studio development environment.  Thanks for that fix Jim!