You could trying opening a technical support case, but I do not believe there is a way to remove the disk or force a swap with a smaller disk. Adding disks is like carpentry - measure twice and cut once.
If you have a good relationship with your NetApp reseller, you might convince them to let your borrow a "swing" or loaner shelf to migrate your data to another aggregate, destroy your aggregate, and then migrate the data back. When I was in NetApp Professional Services, I did this at least twice a year for customers when they added the wrong size drives or accidentally added all their spare drives.
Some of the migration aspects are coming, but somethings even NetApp can't change. I'd like to see "data move" in ONTap 8.x be able to move CIFS/NFS shares as transparently as it is supposed to be able to move LUN's, at least within the same controller. I guess that would essentially make such moves possible with entire aggregates as well, but the complexity and duration of such an operation would have prohibitive risks in today's world, I would think...
Upgrading disk sizes is a phenomena that has only recently gained speed. Since the availibility of consumer grade ATA/SATA disks that were forced to compete on a purely per GB price market, sizes have expanded rapidly. It hasn't really been a necessity. You could by 144GB disks for many years, for example. The pace was slower. Perhaps this wasn't one of the highest priorities when WAFL was made.
The file system would have to be modified to understand the modifications in physical storage that were occurring somehow. I think calling WAFL a mantra is pushing things a bit far. Given enough time, money, and human resources, it probably can be done, but NetApp is a company that needs to make a profit and not an academic institution developing solutions for historic corner cases. It may become necessary, but it hasn't been so far, I would think. I don't believe there are any competitors that offer this functionality either.
Unfortunately, unless you can move the data and delete the aggregate, you can't. I've always found this a bit puzzling myself, but I've had occasion to have gotten "odd" size disks (a 250GB disk in an otherwise 500GB aggregate via 'vol/aggr add' and basically, the size of that disk in that aggregate will simply always remain the same.
If the situation, for example, were reversed, and you had a single 1TB disk in a 2TB volume, when that 1TB disk failed, a 2TB replacement would only ever use 1TB of that disk. (The same is true for my case above with the 250GB disk, btw).
Unless something has recently changed in ONTap, you basically just donated a 2TB disk for a 1TB job. Experience is sometimes a painful thing, unfortunately.
I almost hope that I am wrong, but based on my previous experiences, the size of that disk in that raid group can't be changed after it is added. You can always give it a try, but the reconstruction time could be pretty extensive (especially with -i). Basically, it would want to do a preventive copy of all of the blocks over to a new disk (without -i), so it has to be of the same size. Even the parity rebuild will want to produce the same number of blocks on the replacement. I believe you are in the same boat if you use disk replace as well.
There's probably a KB article that makes this information more official on the NOW site.