You can override the WF constructor in your application so that end users change workflows. When you accept a designer, you pretty much control what they can do. For example, you can prevent them from deleting or disabling actions and allow them to add certain new actions to a predefined area of the workflow. The best approach is to save these workflows as XOML files and run them as such. This means that you cannot add code to the workflow, but you can define your base workflow class derived from SequentialWorkflowActivity (or the state equivalent) and use it as the base workflow class. This allows you to add code and properties. For example, you can still add CodeActivity, but you need to associate the code with the base class.
Serialization of a workflow or dehydration, as it is called, is used to execute workflows to save them to disk. This uses standard .NET binary serialization and can be quite complicated due to the lengthy nature of the workflow. But it doesn’t matter when you know what to look for. See http://msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx for a series of blog posts.
Not sure if you need it, but there is an opportunity to change already running workflows. To do this, use the WorkflowChanges object. See here http://wiki.windowsworkflowfoundation.eu/default.aspx/WF/RuntimeModificationOfWorkflows.html for more details.