Yes, it should work (you missed step 2b), partition new disk, and 6b), enlarge filesystem).
More about Alt-F latter.
But you don't need to break the mirror and copy data. Replacing disks is like repairing a degraded array, you deliberated make each disk to "fail", one at a time. And the data will always be available without downtime.
The following is only for metadata 0.9 and if the new disk is smaller than 2.2TB, as bigger disks require RAID metadata 1.x and that can't be changed without breaking the array:
1-fail, then remove one disk component from the array, then unplug the disk. the arrays is still be working in degraded mode
2-insert the new disk and partition it, one partition of type RAID (this is an Alt-F RAID webUI requirement)
3-add the new disk RAID partition to the RAID as a new component and wait for rebuild to finish and the array leaving the degraded state
4-repeat step 1,2,3 for the other disk
5-enlarge both disks RAID partitions (watchout, ***DON'T*** change its start sectors!)
6-remove write-intent bitmap from the array, enlarge the RAID, re-create bitmap
7-enlarge the filesystem
All the above can be done using the webUI.
Step 1 can be done using Disk->Maintenance, Eject, which will stop swap on the disk, unmount all "non-RAID" filesystems, fail and then remove all disk RAID partitions from RAID arrays (I haven't tested this for a long time, hopefully it will be still working, check it's OK before continuing with step 2)
Step 2 partitioning can eventually make step 5 unneeded, not sure. If the RAID partition in the new disk is created with the desired final size, only part of it will be used.
From the mdadm manual:
SIZE CHANGES
Normally when an array is built the "size" it taken from the smallest of
the drives. If all the small drives in an arrays are, one at a time,
removed and replaced with larger drives, then you could have an array of
large drives with only a small amount used. In this situation, changing
the "size" with "GROW" mode will allow the extra space to start being
used. If the size is increased in this way, a "resync" process will
start to make sure the new parts of the array are synchronised.
Note that when an array changes size, any filesystem that may be stored
in the array will not automatically grow to use the space. The filesys-
tem will need to be explicitly told to use the extra space.
Also the size of an array cannot be changed while it has an active bit-
map. If an array has a bitmap, it must be removed before the size can
be changed. Once the change it complete a new bitmap can be created.
That's OK. For everytime usage there will be no problems with that, only flexibility might be missed, because you have to "unmount" Alt-F when disk maintenance is needed.
E.g., if you ssh the box you might find that you can't unmount filesystems, or you might find that you can't use your favorite text editor, or...
The normal setup is to have Alt-F as one folder in the user filesystem, but if you have empty sda4/sdb4 inherited from the D-Link fw, then using them for Alt-F increases flexibility.
The Alt-F data is not critical, it's not like your child anniversary photos, you can always re-install Alt-F packages latter, you only have aditional work setting it up again.