As your API is build around the UUID being the key for these rows you are stuck with that as your functional primary key at this point, though that in itself is not a bad thing. Clustering on a UUID column is not recommended though due to the randomness of the incoming values - this causes a lot of page splits and fragmentation on the clustered index as you have noticed.
Your suggestion of adding a new incrementing integer key as your clustered index would work fine, though I would not make it the primary key because functionally speaking the UUID is still the primary key. Keeping the data layer and application layer in sync on this will avoid potential confusion later. Keeping the UUID as the PK will also avoid you having to change all the tables that have foreign key relationships with this one (and the code that interacts with those tables) to account for the new data type in the key.
Adding the new integer values for the clustered key in this way is essentially emulating the RID of a heap based table (one without a clustered index), though it is smaller than a RID or your UUID (at 4 bytes rather than 8 for the RID or 16 for a UUID), assuming you stick with an INT not a BIGINT, so will save space both with this key and on every non-clustered index in the table (non-clusered indexes on a table with a clustered key contain the clustered key value for every row so by going from a UUID to an INT for the clustered key you save 12 bytes per row per index). This doesn't mean you should always use INTs as your clustered keys as there are a several other considerations beyond index size that affect the best choice of clustered key for any given table (for instance: if you have a candidate key in your real data that is likely to be subject to range queries than this is often, but again not always, the best choice).
