I followed your link and looked, but all I saw was a pretty diagram consisting of colored boxes with buzzwords in them arranged in a grid, and a little marketing hype. The only other links I saw were to 'screenshots'.

From the phrasing of your OP

After spending the last several years working on projects that ended up needing these kinds of tools, I finally decided to sit down and write them.

this would appear to be a one man development effort, so the text in the boxes:

• WWW-live server.

  What's the alternative to a "live" WWW server? A dead WWW-server? An offline WWW server?

• Customer Extranet.

  What does this mean? Something more that you can give customers an ID?password to logon to one or more of your systems?

• Document Server.

  Documents? Like HTML files? But that would be a web server.

  Maybe .PDF files. Hmmm. Documents live in files. So a 'document server' is just a 'file server'.

  Unless this is one of them guys in a classy suit that walks up to you, asks: "Are you Mr. firstname lastname"? And when you confirm your identity, 'serves' you with some 'documents'?

• Messaging server.
• Notification Server.
• Scheduling server.
• Event stream.
• Subscriber API.
• Publisher API.
• Public API.
• Web services.
• Bulk email server.
• Datapipe server.
• Portal server.
• WWW-Dev server.

  Ah. This is the alternative to a 'live' WWW server--but isn't the difference between them that one is web facing and one is not? If the difference is more than that, doesn't that mean that once I've developed and tested my applications on my WWW-dev server, I have to re-test my applications on my WWW-live server to ensure that they run there also?

All that leads me to these possible descriptions:

• Overambitious.
• Available "Real Soon Now".
• Why does this guy think that he can compete with, never mind surpass, these existing suites?

Sorry if that sounds cynical, but your 10,000 foot overview tells me so little about your development platform that it is a bit like trying to describe a property after being pointed at an ariel view of it taken from a similar height. "It's that slightly darker grey pixel just there."

First: Thanks for taking the time to look around at it and write such a detailed reply.

As for the ambiguous language used to describe what each portion does - my forté is coding, not marketing-speak. I am working on some much more in-depth write-ups about each piece and its function within the whole. I'll try to summarize these pieces here:
• WWW-Live Server:
  s/Live/Production/ - The publicly-available version of websites managed by the system.
• WWW-Dev Server:
  The preview/special-access-only location of websites managed by the system.
• Customer Extranet:
  An authenticated portal-esque site intended for sharing customer-specific information with trusted 3rd-parties. Orders, pricing/quotes, specialized data-exports, etc. Ideal usage would be a B2B supplier portal, wholesale distributor portal, etc.
• Document Server:
  A web-based file server that offers versioning, permissions, forced SSL downloads and view-tracking. Since it is also tied in with the rest of the system, it can generate events (i.e. - "Bob downloaded the proposal").
• Messaging Server:
  *Not* instant messaging. It's more of an asynchronous, distributed publish/subscribe model. The Messaging Server just helps connect the dots between the events that are raised and objects that are listening for those specific events.
• Portal Server:
  This is what the screenshots are of. The admin console, basically. Although the basics are covered (user administration, permissions, documents/contacts/settings) its main purpose is to serve up all your CRUD pages. It uses a series of widgets that simplify things like lists and form-generation so that you only have to code what is absolutely necessary.
• Public API:
  Rather than hiding functionality behind a wall, all the functionality used within the application is available through the public API.
Admittedly the diagram needs to be updated and the other parts are perhaps a bit "forward-looking" but like I said in my original post, these are the kinds of tools I kept finding I needed, but didn't have. My hope is that together they help speed development by removing some of the tedium of web development so that the focus can be on adding real features and functionality.

"Why does this guy think that he can compete with, never mind surpass, these existing suites?"
Having worked with WebLogic and JBoss, I feel that they are slightly overrated. They have some great features but to get anything done just requires so much effort even from experienced developers. There are other open-source "portal" servers as well:
• Metadot:
  Have you actually downloaded the code and looked at it? HTML embedded within Perl. Not my idea of How Things Should Be Done.
• Mambo:
  Mostly focused on content management. Written in PHP. Functions interspersed within display-layer code. HTML embedded within application code. Lots of SQL embedded within application code. At first glance it looks wide open to SQL-injection attacks.
• Apache JetSpeed Portal:
  Every download link for the source leads to a 404 error. Considering there are lots of people working on this, I can only assume it's worth looking at. It appears to address the same kind of problem-domain that other Java portal servers address.
• Bricolage:
  Focused on content-management. Not an application development environment.
• Vignette:
  If you're starting up a (well-funded) online newspaper, Vignette might just be your cup of tea. Otherwise, keep shopping.
• Siebel/Peoplesoft/Dynamo/WebSphere/WebLogic:
  If you have a million dollars to spend, a dozen people to manage and a year to wait, check these guys out. YMMV
I have never been impressed with something just because it's written in $Language, or because it costs $Price, or because it comes from $Enterprise_Level_Multinational_MegaCorp. I know that necessity is the mother of invention, not over-inflated budgets and shiny suits.

My goal with this project really is to provide a platform on which to develop web-based applications. I'm just not sure what to call it, or if it's really necessary to come up with an "umbrella" name to group everything under.

Ideas?