Let's assume that we have a XAML in the Assets folder. The XAML is linked into Blend.

If you want to edit event-handlers in Blend, you need a code-behind. Without it you will get an empty panel except for the message that you have to add a code-behind.

So far I have identified 3 situations:

1) When you create a code-behind compatible with Blend in the Assets folder, Unity will complain that it doesn't recognize the System.Windows namespace.

2) When you create a code-behind in the compatible with Unity in the Assets folder, you need to add a ton of references to the Blend project. That makes Intellisense incredibly slow. Also Blend becomes unresponsive for a long time when the assembly is updated by Unity.

3) When you create a Blend compatible code-behind in the Blend project folder, Blend won't recognize it as a code-behind. I think the code-behind is expected to be in the same folder as the XAML.

An annoying work-around is to move the code-behind into the Asset folder when you need to edit event-handlers in Blend and move it back out or change the file extension when you return to Unity.

Is there a better way?

Alternative solution: dummy System.Windows classes. Some possibilities for improving Blend support

If you take a look at our demos in the Showcase, we are wrapping .cs code generated by Blend with #if defines (#if !UNITY && !UNITY_EDITOR ...), so Unity ignores it.
The other way you simply don't add the scripts generated in Unity to the Blend project, so Blend doesn't try to compile them.

But the solution provided by @wckdspn is something we are analysing to make the integration with Blend even better.

Thanks, I feel so stupid now. I never even looked at the *.xaml.cs files in the assets folder of your samples. The answer was right in front of me!