This issue was a huge problem for me for a few years. For Populr (https://populr.me), we created an entire theming system for our users. That, of course, means users could write css that would override our interface, since page editing is truly wysiwyg on Populr. To get around this, we actually split the display of the page and the editor up. The page is displayed in an iframe, with the theme's styles, and almost all of our editor is overlayed on top of the iframe. It get's kinda crazy at times, but it works pretty well.
Now, on a new product we are developing, We are taking the opposite approach. For TouchStream (https://touchstreamapp.com), we needed a rich text editor for users to edit their emails. We went with Redactor (http://imperavi.com/redactor/) for the editor. However, Redactor is a contenteditable editor, so it was inheriting a bunch of styles from our interface. Not exactly what you want when editing emails. In this case, I used a modified version of Cleanslate (http://cleanslatecss.com/) to reset all of the elements within the contenteditable to their browser defaults. It's not perfect, but I got it pretty close. It's the best you can probably do until scoped styles become more prevalent.
Edit: to be fair, Cleanslate is more of a polyfill for a combo of the css keywords "initial" and "unset".
I was wondering this as well - would be interested in the answer.
Years since I've really dabbled in WYSIWYG editing JS, but the best I can think of us to use a reset CSS file namespaced for the `div` (or whatever container) in question.
I would love to hear your plans to overcome this as it is pretty much a hard requirement for any editor integration.
I have run into this and was quite hopeful about <style scoped> but browser support leaves much to be desired.