You can create and aggregate with mixed disc sizes (and speeds if you're really strapped for like for like discs)
If you add the 144 Gb discs first, and then 300's, by default some of the 300's will get sized down to 144, until you start a new raid group. This will give even performance though.
If you add the 300's first, you will get all the capacity of the 300's, and when you add the 144's you get all their capacity too, but some data is striped over only the 300Gb discs so performance could arguably be more random.
After you choose what to do, I would create the aggregate manually adding a few discs at a time to ensure you pick the discs you want to give the solution you want. For this query, 32/64 bit is irrelevant. Pick one and go with it. The underlying raid group concept is the same.
Note that the parity disc(s) determine the maximum usable size of any drive inside that raid group. If your parity disc is 72GB, no matter what you add, all bigger discs will 'right size' down to 72Gb. (There is a method though to change the parity discs for bigger ones without data loss though, but better avoided if you can)
You can have many raid groups inside an aggreagate. If you start with 300's, then add 144's, using the default raid group size of 16 for DP, you'll end up with an incomplete raid group made up of 144's. If you then buy some more 300's and add them into the aggregate, they will likely finish off a raid group so you'll only see 144 usable from those new discs.
Assuming they are DS14's with 14 discs, you could set your raid group size to 13, keeping one spare. Then, add in 13 x 300 Gb discs, and then add in 13 x 144 Gb discs. This will ensure 2 completely full raid groups, and should you ever add any more discs, they will start a new raid group in the aggregate and be fully utilised.
Hope thats helped. Most documents would say mixing disc sizes is bad but personally, unless performance is a real critical concern right now, I'd always look to maximise disc capacity by creating the fewest number of free space pools possible, ie 1.
I've seen production filers running 72, 144 and 300's in the same aggregate. You wouldnt design it like that, but it works just fine.