META: Convert pseudo fields to real fields.

I don't think this is a good idea. Most properties of the aegir nodes are critical and would break if customized in any way.

Before we proceed any further in thinking about this, let's list the "fields" that would be good candidates to move to field.module fields.

I can't think of any at the moment that would benefit in any way from being full drupal 7 fields.module fields.

Also, from my experience, EntityFieldQuery can be quite a pain in practice. I don't see any benefits to using that instead of simple db_select() calls.

Making them managed by the field system would allow administrators to better control the order and display of the fields. Using display suite layouts for example.

As well as making it easier to add additional fields for their own purposes (site notes etc).

Here are the fields for the content types that are shown on the creation forms, I've taken the liberty of updating machine names to make them easier to grock when looking at code.

Server Fields

field_title: Server hostname (text)
field_server_human_name: Human-readable name (text)
field_server_ip_addresses: IP addresses (text: * 3)

field_server_http_type: [no label] (select: radio)
field_server_http_port: Port (text)
field_server_http_restart: Restart command (text)

field_server_db_type: [no label] (select: radio)
field_server_db_port: Port (text)
field_server_db_username: Username (text)
field_server_db_pass: Password (password)

Platform Fields

field_title: Name (text)
field_platform_make_file: Makefile (text)
field_platform_make_option: Drush make option (select: radio)

Site Fields

field_title: Domain name (text)
field_site_profile: Install profile (select: radio)
field_site_platform: Platform (select: radio)
field_site_language: Language (select: radio)
field_site_db_server: Database server (select: radio)
field_site_redirection: Redirect all domain aliases to (select: option list)
This is a separate issue but I'd personally like for the redirection option to be per alias
field_site_alias_[delta]: [no label] (text)

Client Fields

field_title: Client name (text)

All the above fields should only allow changes to label, description, field order on edit form, and order in display modes.

I have to agree with Jon here. This is a lot of work for what amounts to cosmetic benefits, at this point. That said, I think this'd be the way to go for a D8 port, along with moving to entities. The main benefit that I'd see there is the RESTful interface it'll provide. That, in turn, will allow completely custom front-ends, whereas we'd just be providing a default UI.

Bear in mind that the server fields are defined largely in hostingService classes, which have some form helper methods. I believe the display on these is broken, at the moment, since it should only be displaying the settings specific to the active service type. Better utilizing the D7 FAPI would be a good start towards this. Also, I think DX would be improved by #2457425: Allow services to be associated with other Hosting entities.

For reference, I've been thinking about this a bit lately, and I think a hosting_service entity on which we attach our various fields may be a more useful than trying to define each of fields required for the current node-types. I wrote up some preliminary ideas in https://www.drupal.org/node/2457425#comment-9894111