Agreed that it should be reasonably easy now to come up with a working bundle.
The standard folder for internal (or private) frameworks is PrvFrameworks. The structure of an application bundle is essentially this (i'll use glest.app for the purposes of the example):
glest.app (the application)
-- (anything else)
The info.plist file stores the application properties - things like who bundled it, what its called etc. It's auto-generated form the XCode project (or from the PackageMaker).
The Resources folder contains things like icons and any GUI bits and pieces that may be needed by the application for it to display appropriately in Finder. For the purposes of Glest (incl GAE and MG), that folder will probably just contain the icon (in a .icns file).
The MacOS folder is what effectively stores the binary - it's what gets built by XCode and what is actually run by MacOS. This content is generated entirely by XCode so you don't have to worry about that.
The Frameworks folder contains all of the private frameworks (libraries) that are required for the application. Yggdrasil is right - this is where things like Xerces.Framework, OpenAL.Framework etc should go. In the current MegaGlest app (I can't seem to compile GAE, but I can get MG working), Xerces, Vorbis, SDL, ogg and libpng are all present in there, as is liblua.dylib. So most of the frameworks are there, but it would be good to include everything required. It also means that if an update by Apple is released and one of the system frameworks is updated and the update breaks the glest code the game won't break - it'll continue to use the private version (at which point developers can work out what changes need to be made to the code to use the new framework for the next point release).
Because bundles can include other stuff, you can add folders in here (such as a data folder) that would contain all of the GlestData. The only problem with that is it makes it indirectly accessible (i.e. you can't just navigate to it - you need to Open the package contents before you can access it), so the better option would be to install the glest data in /Volumes/System/Library/Application Support/MegaGlest (or GAE or Glest as appropriate). By using that folder the data is accessible to all users (~/Library/Application Support is user specific) and easy to access by browsing the filesystem. It also means that updates to the data can be installed without having to stuff around inside the application bundle (a good idea, particularly for non-tech ppl).
As for how to package other apps (like the map editor for example) - the Mac way would be to actually create 3 application bundles that reside in a folder, and that folder gets installed into Applications.
i.e. instead of:
you would create them like this:
All three would essentially be separate applications, but you just make sure they reside in a common location and you should be able to use relative paths to point to any resources that may need to be accessible in other apps (so yes, you can point to ../megaglest.app/resources if need be).
PackageManager could be used to combine all 3 application bundles later for distribution if need be - that's something I'm quite good at even though I'm still getting my head around some of the other dev aspects.
I think we're at a point where there's a REALLY good opportunity to get Glest out there and a bit more visible. If you weren't aware, Apple have just announced OS X Lion and part of that includes the introduction of the Mac App Store (like the App Store on iOS). If we could get Glest bundled up and working properly before the App Store comes out (which is due in abt 3 months), then it could become a good way of getting exposure for it!