Something like that seems horribly hard to get right.
Forget about cross domain scripting attacks, now you can't trust JS from the point of origin. Yet at the same time, you'll probably want it to be able to do all sorts of fancy AJAX-y stuff on the decrypted content. (Certainly on other parts of the page.)
You're right, in order to get the security right, you wouldn't be able to access the decrypted content with javascript. The browser would prevent that from happening.
Yes, potential functionality would be lost, but that's always part of the trade-off for security.
But I don't think the trade-offs would be detrimental, from a usability standpoint.
From a user perspective, how would you identify "safely" encrypted elements, in a way that can't by spoofed by the page rendering a nonencrypted element with appropriate styling?
Could be the same way the browser identifies "safely" implemented HTTPS (ie, popup, icon, etc). A nonencrypted element with appropriate styling would not have the same browser-level indications that an encrypted element had.
Forget about cross domain scripting attacks, now you can't trust JS from the point of origin. Yet at the same time, you'll probably want it to be able to do all sorts of fancy AJAX-y stuff on the decrypted content. (Certainly on other parts of the page.)