Just make a backup first, as always. Switching engines will copy the contents of the table into a different file on the hard disk... if you have gigabytes of data that could take minutes or hours, if you don't, then it can be a few seconds. Your disks can probably only copy 50 MB/s or something around there since they won't be totally idle at the time, so you can do the math and figure out how much time you need before switching if it's important. Or just take note of how long it takes to make a backup of the table, that'll be about the same.
I do over a million of those "UPDATE table SET views=views+1" queries a day for W3Counter. That's in addition to a couple million INSERT queries a day happening at the same time on other tables. That's on each DB server, which aren't super servers considering the workload... just a single quad-core Xeon processor and 8GB RAM each.
I didn't have an issue doing that with either MyISAM or InnoDB. The table with all the updates usually has around 10 million rows in it.
I did eventually settle on InnoDB as the better choice for my usage, but the database is overall a hybrid, as MyISAM has other advantages I exploit on other tables. Just makes balancing the settings for various memory pools and per-query buffers a little more difficult.
Are you sure the delay is because of locking? I don't know that I'll be able to tell you something useful, but I'm curious about this... run a SHOW STATUS query, what are the values for Table_locks_immediate and Table_locks_waited?