Putting the build files directly in the workspace folder is a very bad idea for many reasons and this is why it seems just impossible to do so. The workspace is just that.. a project container.
I see two ways to go about your situation :
1 - Create a master project that will serve the same purpose as your workspace. Then move all your projects as sub folders of this project folder. You will have the folder structure you want. To fix the project structure and get back each project in the workspace you can use the import function and import an existing project. Make sure you do not select copy in the workspace option of the import. This will allow you to have a project in your workspace folder that does not actually live in the workspace directly. Newer versions of eclipse will handle correctly nested projects like this, older versions could not. Note this technique also works for projects that are not sub folders of the workspace, they can be anywhere on your hard drive and still show up in your eclipse workspace UI.
2 - Another option is to create a master project but leave everything at the same level (do not place project-components inside the project folder) Then arrange your build script to refer to the other projects via relative paths. Note that with some build tools this is not even necessary as they will look at their repository.
I have used both layout successfully in builds with Ant and Maven. Going to try Ivy soon cause Maven is as painful as it is blessfull. Most likely an Ant-Ivy combination donno yet.
In a personnal note I think the second option is better suited for scalability. Since all projects are on the same level it makes it easier to reuse a component-project in other master projects without having to make exceptions. Basically you end up having two types of projects. The actual code projects that are the building blocks of your application and the assembly projects that create the final finished product. That way you can get a good separation between the build mechanism for your products and your project. This is another way that maven irritates me as for many options we must pot them in a master POM that projects inherit from. Now to build things slightly differently in different projects one has to augment the master POM with specificities of each. I would much prefer placing this in the master project than having to spread it all over the place.
Anyways, my 2 cent, I hope this helps.