You'll face the same problem that any disassembler has: you don't know the meaning of things.
Real life example i had last week: when i saw the value
0x00408800 passed to a function, i was certain this had to be a bit mask. After a lot of tracing, and seeing the value was stored somewhere, copied somewhere else, used in a class constructor, and accessed in a method of a subclass, i figured out that this was actually a memory location, which happened to be part of a larger array, so it didn't even have a symbol on its own.
And, if it had been an indirect call instead of a memory access, this would have turned the meaning of the bytes at that address from data to code.
Unless your code verifier / disassembler generates a list of every possible state of the program and RAM, and as a results, knows where every literal value might be used, and knows where every used value might be calculated from, you won't be able to find such ambiguities automatically. But, this is only one example for an ambiguity, and i suppose being able to differentiate between a memory location and a bitmap would be quite important for any kind of code verification.
So, unless you make a lot more assumptions (code is generated by a specific compiler that emits a finite number of basic blocks that are combined only in specific ways), no, i don't think it's possible.