microsoft sql server schema From blog.sqlauthority.com:


  Protecting ISV database access: in custom ISV (Independent Software Vendor) applications, the database schemas are usually complex, and in the case of applications such as Siebel and SAP, they are tuned for specific application access paths by using many customized indexes. Ad hoc access or alteration to the underlying base tables of these applications can severely impact performance of queries and the application itself. Using schemas, a developer can logically group objects and even create custom objects without running the risk of messing up the underlying ISV database


I have a vendor MS SQL Server 2008 R2 database that I need to add tables to in order to track timestamps. However, I am not allowed to modify the vendor's schema in any way, which is the "dbo" schema.

Would creating a schema new schema in the same database sufficiently isolate my proprietary objects from the vendor's so as not to interfere with things like vendor updates?
You will almost always be susceptible to vendor updates when it comes to schema changes and their app, especially when it comes to ERP applications such as SAP Business One or it's bigger brother.  

The issue is how will their update scripts react to your table being added/modified?  Usually it's not a big deal for me but sometimes it could cause massive problems, up to silently causing issues which no one finds out until they realize their billing data is wrong or something of the sort.  If you include FKs which you probably will, note that changes to one table might also affect updates.

Problem is you need to actually make changes like this.  My suggestion would be to be open with the vendor, tell them you need this functionality so they add it to their requested features and in the meantime try to get their support on making your own tables in their app's db.  Their answer will most likely be 'we don't recommend it and we don't support it'.  Thus you should always have steps on handling this data before and after upgrades.  You could have processes based on how/when the data is accessed where you could remove the table or FKs and recreate after the update.  You'd need to track the changes diligently.  

Edit:

*and hire a QA contractor 1 time or utilize a good one to have tests written before/after upgrades that cover many if not all edge cases if it's really important.