Instead I'd like you to discuss just creating it as a Non-clustered Index Unique Constraint on the database side - you still get the primary key, you still get it indexed but you don't suffer the performance hit on the database - if this isn't the case as I
believe and have read and been told by SQL MVP's then I'd be happy if you loop someone in on the discussion to correct me.

That way we can still create random GUIDs on the client side, we can also insert new records in multiple instance of the database and not have replication concerns, and we don't need to resort to using sequential uniqueidentifiers on the database.

This was discussed again and we decided for several reasons to not make any additional changes here beyond the change already made to add clustering as part of the Migrations fluent API. The reasons for this are:

The SQL generated from Migrations for SQL Azure will not work for the common case of a GUID primary key. We could special case SQL generation for Azure to still generate a clustered index, but this would mean that if you want a non-clustered index on Azure
you would have to override the SQL generator to do this, even though "clustered" is being passed as false in the Migration code. It is entirely reasonable to want a non-clustered index on Azure for cases where you have another column with a clustered
index, so it should be easily possible to do this.

It is reasonable to want a clustered index in some situations when using a client-generated GUID key. For example, it is a known pattern to use a sequential GUID generator on the client. This doesn't seem common for EF currently, likely because EF doesn't
have such a built-in generator, but it could get one in the future.

Doing this would add complexity to the mental model of when a clustered index is generated and when it isn't. It's not clear that the value added is worth this additional complexity in the mental model.

What this means is that as it stands client-generated GUID primary keys will have "clustered" set to true by default just like other keys. To get a non-clustered index, just change the PrimaryKey call in the Migration to include "clustered: false".
For example: