You don't want to use newid() to determine your id field, since this will be recalculated every time you use the view. Really, data integrity is the biggest issue.

select
row_number() over (order by someStaticAndUniqueFieldLikeCreateDate) as ID,
Field1,
Field2,
Field3
from
tblA
order by
someStaticAndUniqueFieldLikeCreateDate

This only works if you're ordering on a field that will have a consistent ordering that will append new rows, such as a CreateDate field. If you don't have this, that ID is subject to change. Now, if you only need these ID's at runtime, and there's nothing that permanently links to them, row_number will be just peachy keen. If you have unreliable data, there's no way to have a reliable ID field unless you create an additional table and use triggers to populate it.

Secondly, be careful with that with schemabinding. It's dangerous if used as a kludge. Remember that as soon as you create a view with schemabinding, you cannot alter the schema of any underlying table at all. This means you can't make a varchar(50) column a varchar(100) without dropping and re-adding all views that have with schemabinding enabled. Yes, you can index a view that's schemabound, but there are definitely tradeoffs that need to get taken into account before you go lock, stock, and barrel.