Is this an ok "poor man's 2 out of 3" key solution? In the situation that you want no individual to have the complete private key, but you do want  to share the complete key between 3 individuals, of which any 2 can construct the complete key, what is the downside from doing something like this:

Orig key = 1 2 3 4 5 6 7 8 9 (abbreviated for demo)

key 1 = 1 2 _ 4 5 _ 7 8 _

key 2 = 1 _ 3 4 _ 6 7 _ 9

key 3 = _ 2 3 _ 5 6 _ 8 9

obviously any 2 keys would construct the entire key again.

Apart from the decrease of key strength to 1/3 of the original, are there any other potential issues ? 

This would be used for "short term" escrow accounts where, in the case of a "winner takes all", the escrow would just communicate their key to whichever counterpart won. If the escrow failed to send, then the counterparties could choose another (trusted) escrow and transfer the funds to them.
There are two problems with your approach. The second one's more difficult to solve than the other.

Problem 1

While it would take me a 100 million years to brute force the key 1 2 3 4 5 6 7 8 9, if I know two thirds of the key, it doesn't take just 1/3 the time, but a cube root of the time, meaning that I might actually be able to guess it.  

Giving everyone a part of the key without making bruteforce faster


Instead, you generate 3 totally random strings of bytes as long as the key. We'll call these R1, R2, and R3.  
We'll call the private key K, and the clients, C1, C2, and C3.  
To C1, you give R1, and R2 ^ K. (^ is shorthand for XOR)  
To C2: R2, R3 ^ K  
To C3: R3, R1 ^ K  


Example: If C1 and C2 put their heads together, they could combine R2 and R2 ^ K. This is important, because R2 ^ R2 ^ K = K
Space requirement: Given that n = number of people, and m = maximum number of people  abstain, you need n!/m!/(n-m)! ciphertexts. Okay for 3 people, starts to get unwieldy for 10.

Problem 2

When generating the key in the first place, somebody needs to know the full private key before they split it up. In other words, you need a trusted third party. To get around this, you need to do something called Distributed Key Generation. I'm not sure if this can be done for ECDSA. This paper looks encouraging based on the abstract, but I can't see the whole article.

Multi-signature transactions

This is a much more scalable and secure system. Unfortunately, it's not really ready for real-world use yet.