I haven't tested this on Azure, but on my local SQL Server 2016, I cannot reproduce what you're seeing. Perhaps the target user has more rights than you think? Do they have membership in a role that is giving them access?
Anyway, the testbed I used to test this is:
CREATE TABLE dbo.SomeTable
SomeTable_id int NOT NULL
PRIMARY KEY CLUSTERED
) ON [PRIMARY];
CREATE USER UserA WITHOUT LOGIN;
DENY SELECT ON dbo.SomeTable TO UserA;
GRANT CREATE VIEW TO UserA;
GRANT CREATE SCHEMA TO UserA;
EXECUTE AS USER = N'UserA'; --anything past this point is executed using UserA's permissions
--fails with SELECT permission denied
--this works due to the GRANT CREATE SCHEMA statement above
CREATE SCHEMA UserA;
--this works due to the GRANT CREATE VIEW statement above
CREATE VIEW UserA.SomeTableView
--this fails since the user who created the view doesn't have rights to the underlying table.
DROP VIEW UserA.SomeTableView;
--revert back to "me" instead of UserA
UserA is able to create the view, but they cannot actually select from it. The error returned is:
Msg 229, Level 14, State 5, Line 27
The SELECT permission was denied on the object 'SomeTable', database 'MaxTest', schema 'dbo'.