There is no concept in SQL of physical order of rows stored in the table, and there is no syntax to support it. Rows are considered to be an "unordered set", and it is at the discretion of the RDBMS implementation how to store them, and how to return them in a query.
That's the disclaimer to satisfy the RDBMS purists. In practice, there _is_ a physical storage order, and as long as you avoid things that may sort the rows as a side effect (like DISTINCT or GROUP BY), you can make this work.
Here's what I would do:
1. Add an "ordering" column to both tables:
ALTER TABLE maintable ADD COLUMN ordering INTEGER NOT NULL;
ALTER TABLE extratable ADD COLUMN ordering INTEGER NOT NULL;
2. Populate these columns with the storage order. This is the controversial part. How do you know UPDATE will use the same ordering as a SELECT? MySQL makes no claim or guarantee of this, so you should double-check the data afterwards.
SET @i = 0;
UPDATE maintable SET ordering = (@i:=@i+1);
SET @i = 0;
UPDATE extratable SET ordering = (@i:=@i+1);
3. Add the cellphone column to maintable:
ALTER TABLE maintable ADD COLUMN cellphone VARCHAR(30);
4. Use a multi-table UPDATE to copy cellphone values from extratable to maintable:
UPDATE maintable m JOIN extratable e ON USING (ordering)
SET m.cellphone = e.cellphone;