Is it unwise to run replication on same physical server?

For redundancy in terms of system reliability and data safety running a slave on the same machine as the master offers you nothing (or close to). If something bad enough to bring down the master happens it will probably bring down the slave too.

For purely segregating users for access rights reasons, a good RDBMS will offer more effective ways of doing that.

Running the two databases on the same machine will require more RAM to run at the same efficiency as the two databases will compete for space to keep they various buffers and caches. There might be a performance benefit though via IO-load segregation, if the datafiles for the slave are on different physical drives than the master. In this case you can run complex reports that required many disk reads against the slave without competing for the master for drive IO bandwidth.

Edit: as DTest mentions in his comment below, one other possible benefit of a slave DB (even if on the same drives as the master) is that complex long-running queries in the slave that might otherwise cause locking issues for the day-to-day-running queries on the master are safer. Though you are still better off having the slave on different drives as such significant queries are likely to cause IO contention issues.

It's not clear to me how this solves your problem. There's no redundancy since it's on the same physical hardware, the same OS kernel, the same MySQL binaries, maybe different disks but on the same storage controller, etc. And the reason for a reporting DB is to offload queries from the OLTP DB and as it's all on the same kit, where's the extra power coming from? Or is there something else you are trying to get from this setup?

One conceivable use for this would be to segregate users somehow perhaps, but again, I would have thought that could have been done with GRANT.

It is indeed considered unwise, are you just trying to take advantage of more cores? What are the goals of the new design consideration?

(posted as an answer not a comment to keep conversational thread focused)