This would make the man in the middle attacks hard to do, even harder with HTTPS:// as the protocol.
Client-side you can not hide code, simple as that, however, you can do things to divert attention towards input elements, generally hackers won't be looking at code, they will have written a crawler to crawl the web and the bot will automatically look for input fields and fill them with data.
So... <input name="login" type="text" value="" /> would draw attention to itself byt the fact that it has something to do with a user login, similar names like username, email, pass, password, pin and anything that is likely to denote an input for a login will come under attack...
Because the web crawler will see inputs, it does not care about specifics like if the field is read only or disabled and hidden doesn't matter, the remote server will still attempt to post data to your server with strings of data in those fields. This can be useful, an input field in a form could be hidden, readonly and given a nice juicy name like userlogin and when your server receives a post, as long as there's no data in that field, it is likely the form came from your server.
So... as long as your web page and server knows the order of things, like <input name="a" type="text" value="" /> <input name="b" type="text" value="" />, etc. and you know that $_POST['a'] "should" contain a users email address, then you can use the common addressed input fields a honey pots and used to validate if your script is being subjected to an attack or not.