Um, way to hard. Also, making your own test data will mean that it will only have features and behaviors you understand before the testing. Use real source data.
Normally the reason for a smaller test database is so that the big scripts will run fast enough on the test machine to have quick test cycles. So, first take a full restore of the production data. Find the big tables, and delete most of the records. One of my favorite ways of doing this, is to delete all the records where the ID (normally an identity int count-up) is not evenly divisible by one of two prime numbers.
Delete from where ((ID/1129)*1129!=ID) and ((ID/1151)*1151!=ID)
This leaves a consistent 0.2% of the data that has variable spacing between records. (0.2% is too much, pick larger numbers; 0.2% is not enough, pick smaller)
If your FKs are setup well (cascading delete) this should complete the task, if not a few more deletes and hurray.
If obfuscating customer data is also a requirement, replace all the consonants in the sensitive data with an X, all the vowels with an A. Now you are ready for tests with realistic values on all the flags, statuses, and other anomalous artifacts in the original data-set.