So to answer my own question....

I created a dummy database on a P1 Pricing Tier and I created a table with MEMORY_OPTIMIZED = ON

An attempt to scale the database to a Standard Pricing Tier failed with an error:

**Failed to scale from Premium P1: 125 DTUs, 250 GB storage, zone redundant disabled to Standard S3: 100 DTUs, 250 GB storage for database: MOTest. Error code: undefined. Error message: The database cannot proceed with pricing-tier update as it has memory-optimized objects. Please drop such objects and try again.**

So that answers my initial question: **You must not do this if you're planning to scale the database to a Standard pricing tier.**

As a secondary observation I note that the message also states: Please drop such objects and try again. I was concerned about that, too (though I failed to mention it in my original question). On a standard SQL database an attempt to create a memory optimized table leads to an message "To create memory optimized tables, the database must have a MEMORY_OPTIMIZED_FILEGROUP that is online and has at least one container."

I was worried that in an Azure SQL database it would do something like that "behind the scenes", and that that alone would suffice to block future attempts to scale back to a Standard pricing tier. That fear turned out to be unfounded. Once I deleted the Memory Optimized table I could scale the database back to a Standard pricing tier again.