WGS84 is not a projection. With ‘-l’, you store the positions as lat/lon coordinates. That means that you have to select the projection later in your application. I don’t know uDIG but I would say that you have to set the right projection there.
Otherwise, you can create the data already projected in spherical mercator with the ‘-m’ flag (which is the default anyway). But for this, you also have to load as prerequisite in the db the sql script “900913.sql” provided with osm2pgsql. Check the wiki.
For the uDig user interface WGS84 means the same as EPSG:4326.
There should be no problem in viewing a map in whatever supported projection with uDig because it can change projections on-the-fly. If you have opened OSM data from PostGIS in native EPSG:4326 projection, just click the projection tab (in the middle underneath the map) and select 900913 (WGS84 / Google Mercator) any other suitable projection from the list and the map will look different.
I tested this with Windows XP, uDig 1.2 Milestone 9 version and PostGIS 8.2. I am not sure if reprojection is done totally on uDig side or if it makes queries to PostGIS with the selected projection. In the latter case also PostGIS must support EPSG:900913 as Pieren told. You can check if with SQL query
select * from spatial_ref_sys where srid=900913;
If definitions for the Google Mercator projection are missing you can find the SQL script from the same place than osm2pgsql utility.
You should see your data also with the other import option that you used. I cannot say why it failed for you. Perhaps the uDig “viewport” was outside the coverage of your data.
As I wrote, I downloaded uDig 1.2 M9 version and it did give me 900913 support out of the box.
I am always testing WMS first with something that gives me a better control about what is really happening. Usually I send hand written WMS requests directly from a browser.
You can see the requests sent by your OpenLayers application from your Apache access log file. With my Windows installation it is under ms4w\Apache\logs. Check that the BBOX and SRS makes sense. To compare with, some OL application using our server is sending something like this:
I suggest also to add DEBUG 5 into LAYER definitions in your mapfile, it will lead to more information logged into your MS_ERRORFILE.
My guess it that there is something wrong with projections and Mapserver just does not find anything from the place defined by SRS and BBOX combination.