If the target device in Step 3 is a whole storage device ("/dev/sda", "/dev/sdb", etc. not a partition like "/dev/sda1" or "/dev/sdb2") then the command overwrites any preexisting formatting and data on the target drive.
The "%" just indicate the terminal prompting YOU for input. So, not typing them is correct.
Try booting the ChromeOS drive on another PC. Even if some critical device drivers are missing, you should get something.
Also, MBRs aren't stored in the BIOS. They are stored at the beginning of a storage device. On traditional PCs, they describe the device's partitions and also hold the code which'll be executed by the BIOS when booting from that device.
Yes, a corrupt MBR on the USB drive will screw up your boot. So, maybe the MBR on the USB drive is corrupt, or your downloaded image is corrupt, or you made a mistake when copying the data.
Ask someone who downloaded the image to post a MD5/CRC32/etc checksum for you to verify that your image file is correct. (run "md5sum -b filename" in a terminal to generate a MD5 value for the given file. If two files have matching MD5 values, it's almost certain that they're identical)
You could also try comparing the USB drive to the image file. "sudo cmp /dev/sdb drive.img && echo match" will print "match", if "/dev/sdb" (hopefully, your USB drive) is identical to "drive.img". Be patient, the comparison will take a while (many minutes).
The following command will be much faster, since it limits the comparison to the first 512 bytes, the MBR:
cmp <( dd if=/dev/sdb bs=512 count=1 ) <( dd if=drive.img bs=512 count=1 ) && echo match