Provided you are formatting the disk with Windows2008 (just guessing, you're using SQL2008 so I hope you're also using Win2008), you'll get an automatic disk partition offset of 1MB. Leave that alone.
If you're using Win2003, then you will need to bust out diskpart and get that offset to 64KB. Terrific that you're paying attention to that. 🙂 For the partition offset, 1024k is fine too, just get it to something at least 64k and divisible by 64k and you're set.
Stripe size: space will not be wasted by using a stripe large than 64k, you're just telling the SAN how to carve up the chunks. In the SQL world, we like to think 64KB all the time (one full extent), but Windows does not see how things are spread across the SAN, it only knows its own formatting (offset + block size). Going with a stripe size wil allow sequential reads/writes of multiple 64KB windows disk blocks, so there is some benefit (demising returns kicks in quick) to going with a lrger strip size, but with a stripe of 64KB, issuing a sequential read of three 64KB blocks will force three parallel reads across three separate disks. with you setup, issuing 20 sequential reads is really a series of parallel but random reads. so, the answer to your question is, "it depends" 🙂
The direct answer is no space will be wasted.
with a 1024KB stripe, there is a potential (big caveat on 'potential') for the writes to perform a single SAN write on multiple blocks, but I wouldn't bet on it. Given then SQL Server makes no attempt to put extents for a single table next to each other, you could just be looking at write contention on a stripe segment.
Now for the decision on stripe size. If you're not going to use a 64KB stripe, any specific choice is dependent on your particular SAN vendor (3PAR vs. NetAPP vs. xxx). I would just default to 'um, cover your tail and stick to 64KB'. Your SAN vendor may have specific guidance for SQL Server, but any vendor advice on SQL Server is "trust, but verify". I've had enough arguments with vendor SEs to take whatever they say with a grain of salt.
I may get taken apart by other folks (who may be far more correct), but once you get the alignment sorted, it's 64k, 64k, 64k. I'm a DBA, so my surly built-in feeling is: stick with published best practices, because your biggest issue is going to be bad code that folks would love to blame on the DBA setting things up "wrong". If you pick a scheme that has loads of documentation behind it, it's far easier to tell them to fix their code, because you have the disks set up "right".