1) Would one embed the script itself in the entity object before persisting to it to the disk? Is this okay?
You'll get cleaner diffs in your version control and encourage reusable scripts by providing the actual script out-of-line and having the entity merely store, say, a filename and script parameters. Storing the script in the entity itself is viable however.
2) Would I compile once per scripting then - this seems like a lot of overhead to store all these compiled Assemblies to execute.
You're looking at a handful of kilobytes on disk per assembly if they're small, and I'd imagine a similarly small runtime overhead. While there are possible scaling concerns (loading 1000s of scripts may have some inefficiencies) you can always start to batch up assemblies at a later date if (not when) you encounter problems. An assembly per script is a simple enough starting point, and as long as you avoid tying large swaths of your codebase to an assumption that will always be the case, you should be fine (just centralize the actual loading of assemblies and extraction of types in one place instead of doing it ad-hoc.)
A bigger concern is if you want to let scripts interact with each other directly 1000 scripts all referencing each other is a PITA to untangle even without circular references: in that case you might prefer to compile, say, on a per-level basis (or just have a single global scripting assembly.) Of course, that might be trending towards putting too much logic in scripts that belongs at a more core engine level.
