It is something that can be caught with static analysis, however. Someone recently put together an appropriate tool[1] for Go, in fact. It seems to work very well.
http://pages.cs.wisc.edu/~liblit/ghc-2011/ghc-2011.pdf
(Incidentally, the hard part of this analysis is not verifying that you checked the error, it's verifying that you propagated the error codes properly—that requires analyzing higher-order control flow.)
I'm not sure I like the idea of special casing _ specifically, but a similarly concise way of saying "if this fails, this thread of execution is FUBAR" would be great.
"!!", maybe?
In C, you can write code that doesn't overload errors and return values; e.g.,
err = someFunction(&returnValue, param1, param2, param3);
I'm not saying this is common -- and in fact the standard C library does a lot of the overloading you're talking about -- but for your own code and functions, you can separate out errors and return values, as shown above.
Honestly, compared to the exception hellscapes I have had to deal with in Java and C++ --- it seems like the path of least surprise. Which incidentally has been my favorite things about Go, the low number of surprises.
A lot of using Go in real work has gone against my expectations. There are a lot of things I initially saw as huge warts (lack of exceptions, generics and import versions), but I liked channels enough (Erlang background) to give it a shot. So far, I have been delighted by using it as a stack (build cycle, deploy method, terse C'ish syntax).