Primary Key choice on table with unique identifier

I'm reconsidering my choice of Primary Key on a table, and would like some input.

Some context: We are building a REST API, where clients access "Assets" identified by a GUID. So, the table for Asset in our database resembles this:

CREATE TABLE [dbo].[Asset](    [Id] [uniqueidentifier] NOT NULL,    [TypeId] [int] NOT NULL,    [Date] [datetime] NOT NULL,    [Title] [varchar](1000) NULL,    [Description] [varchar](max) NULL,    [Created] [datetime] NOT NULL,    [Modified] [datetime] NOT NULL,    [PublisherFields] [xml] NULL,    [StatusId] [int] NOT NULL, CONSTRAINT [PK_Asset] PRIMARY KEY CLUSTERED (    [Id] ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON))

We are experiencing a few problems with this structure, notably that the clustered index on the table becomes fragmented very quickly, and we have now reached the point where we are no longer able to rebuild it (because of Azure limitations on query time limits).

Further research suggests that using a uniqueidentifier as a clustered index is not always a good choice, because of the way that newid() doesn't generate IDs in sequence (unless you use newsequentialid(), but Azure doesn't allow this either).

The simple solution seems to be to introduce a dummy column and add the clustered index to that. Design guidelines say that good clustered indexes should be sequential and non-changing, so the simplest answer to that seems to be an Identity column. This would make my table into this:

CREATE TABLE [dbo].[Asset](        [Id] [bigint] IDENTITY(1,1), <---- NEW        [AssetId] [uniqueidentifier] NOT NULL, <---- Renamed        [TypeId] [int] NOT NULL,        [Date] [datetime] NOT NULL,        [Title] [varchar](1000) NULL,        [Description] [varchar](max) NULL,        [Created] [datetime] NOT NULL,        [Modified] [datetime] NOT NULL,        [PublisherFields] [xml] NULL,        [StatusId] [int] NOT NULL,     CONSTRAINT [PK_Asset] PRIMARY KEY NONCLUSTERED <--- Now NonClustered    (        [Id] ASC    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)    )

The clustered index would also be added to the ID column. Does this seems a sensibible alternative? I might question the sense in having an IDENTITY column on the table that is not a primary key, but my reasoning is that an IDENTITY column is used to obtain the auto-incrementing nature, which suits the clustered index. It might also be confusing...when someone references an "AssetID", which column are they talking about? The [AssetId] column, or the Asset table's [ID] column?

Suggestions and alternatives welcomed.