This isn't too tricky to set up, it's just a matter of making sure you have the right Project Types and Hierarchy Rules defined. A common practice is to create a Project Type to be a "Portfolio" level workspace for organizing other workspaces and projects. A Portfolio Project Type generally is ongoing (no start and end date) with the Phases disabled, and typically doesn't include Tasks, Issues, or other project-related items. It simply provides a way to establish a project hierarchy like you describe above, and you create the correct Project Types as "children" of the correct Portfolio (or Release, Program, or whatever other term is appropriate for your purposes).
A word of caution here, it's easy to go overboard with Project Types, and you may find that the difference between one type and another can be designated by a custom field, such as a picklist to denote what type of workspace the current Project represents.
A good rule of thumb is to stick with a single project type until you find a necessary reason to branch it into two different types. The attributes that are specific to a project type include Phase settings, Hierarchy Rules, External Billing, and the Custom Fields associated with the type. Most other attributes can be differentiated with Custom Fields, and you can leverage Custom Views to appropriately filter the projects.
For example, if you have an open-ended workspace for the express purpose of organizing projects, such as the hierarchy example you provide above, you might create a custom field called "Category" or something like that with the values of "Portfolio" and "Release." Then you can create the hierarchy without having to maintain a third project type:
Portfolio A (Project Type = Portfolio, Category = "Portfolio")
Release 1.1 (Project Type = Portfolio, Category = "Release")
Project X (Project Type = Project)
Project Y (Project Type = Project)
Portfolio B (Project Type = Portfolio, Category = "Portfolio")
Release 1.2 (Project Type = Portfolio, Category = "Release")
Project Z (Project Type = Project)
Be sure to get this all on paper and validate it with your implementation team before you put it into action, as once a project is created you can't change the type. Make sure you have an approach that makes sense and isn't overly complicated, and can grow with the organization as needed. It's always easier to add new project types and fields as you go than try to undo a bunch of configuration once the system is up and running.
One final note here, when you are creating custom fields, avoid using names that are similar or identical to native fields, as it creates confusion when creating custom views and reports, and can produce unexpected/inaccurate results if you select the incorrect one.